[ AGENT IDENTITY ]
Every AI agent gets its own identity.
When five agents share one API key, your audit trail says a key did something — not which agent, or why. SentnelOps gives each agent a distinct identity, so every MCP tool call is attributed, scoped, and answerable.
[ WHY SHARED CREDENTIALS BREAK AUDIT TRAILS ]
A shared key answers “what happened” but never “who did it”
The common pattern today is one service account or API key shared by every agent that talks to a given MCP server. When one of them drops a table or force-pushes a branch, the upstream log shows a single anonymous credential. You cannot tell which agent misbehaved, you cannot revoke one agent without breaking all of them, and you cannot answer an auditor’s most basic question: who had access to what, and who exercised it? Human identity solved this decades ago with per-person accounts. AI agents need the same thing — an identity of their own, enforced at the point where the call happens.
SentnelOps enforces identity at its proxy — the MCP firewall that sits in your VPC between agents (Claude Code, Cursor, custom) and MCP servers (GitHub, AWS, Postgres, internal APIs). Every call is intercepted before the server sees it, attributed to a named agent, and evaluated against that agent’s grants — with under 15ms p99 of overhead and zero data egress.
[ ZERO TRUST: EXPLICIT GRANTS ON THREE AXES ]
Every agent starts with zero permissions. Nothing is implicitly allowlisted — an identity with no grants can call nothing. Access is added explicitly, in plain YAML that is version-controlled, GitOps-friendly, and testable in CI (see runtime policy), along three axes:
Per agent
Each agent — a Claude Code session, a Cursor workspace, a custom pipeline bot — gets its own identity in the registry. Grants attach to that identity and to nothing else. Retiring an agent revokes exactly its access, no one else's.
Per server
An agent granted read access on your GitHub MCP server has nothing on AWS, Postgres, or your internal APIs until you say so. There is no such thing as blanket access across servers.
Per condition
Grants can be conditioned on tool parameters — this agent may merge pull requests, but on main it pauses for a Slack approval with full context. Conditions live in the same version-controlled YAML as the rest of your policy.
[ HOW IDENTITY SHOWS UP IN THE AUDIT LOG ]
Identity is the first field of every record
Because identity is attached at interception time, it appears on every call — permitted or blocked — in a log written to your own database, never ours:
- agent identity— the named agent, not a shared key
- tool name— which MCP tool was invoked
- parameters— the exact arguments sent
- timestamp— when it happened
- decision— permit or block
- policy rule matched— the grant or denial that applied
That turns audit questions from forensics into queries: filter by agent to see everything one agent did, or by rule to see every call a grant permitted. The whole log exports as CSV, structured for SOC 2 Type II — see audit evidence. Blocked calls and approval pauses also raise Slack and email alerts, so an identity behaving strangely is a notification, not a surprise in next month’s review.
Name your agents. Scope their access. Keep the receipts.
The quickstart gets your first identified, logged MCP call flowing in under 10 minutes. Scout is free; Sentnel Starter is $299/mo and Command Team is $799/mo — paid tiers start when you’re ready. Or see what your agents can actually do first — we run a 10-day governance assessment in your own VPC.
Related: MCP firewall · runtime policy · audit evidence