[ LEARN // AI AGENT GOVERNANCE ]
Agent identity in multi-agent systems.
In a multi-agent system, identity design is decided in one place: the orchestrator. It must be an identity router — attaching the acting sub-agent's identity to every call it forwards — not an identity absorber that makes every call as itself. Route identity and you keep attribution and per-agent policy; absorb it and you have rebuilt the shared service account inside your own architecture.
[ WHERE IDENTITY GETS DECIDED ]
Frameworks make it easy to spawn five specialized sub-agents behind one supervisor — and just as easy to give the whole constellation one credential. Everything downstream — policy, attribution, blast radius — inherits that one decision.
[ TWO GRANULARITIES, ONE DESIGN CHOICE ]
Per-call granularity: automatic
Every call that crosses an enforcement point is recorded individually — server, tool, exact parameters, timestamp, decision, rule. The orchestrator being one process doesn't blur this; the request path sees every call it carries.
Per-agent attribution: a design choice
Whether the record says "the researcher sub-agent attempted this" or just "the orchestrator attempted this" depends entirely on whether the orchestrator propagates the acting sub-agent's identity with each call. No downstream layer can recover attribution the orchestrator discarded.
[ WHAT ABSORBING IDENTITY COSTS ]
An orchestrator that makes every call as itself is a shared service account with a scheduler attached — the exact pattern agent identity was introduced to fix, reproduced one level down. Three failures follow directly:
The 3am problem, one level down
Something destructive happened overnight. The audit trail says "orchestrator" — which is true of every call it has ever made. Which sub-agent's plan went wrong is unrecoverable, because the information was destroyed at the moment of the call, not at logging time.
Policy collapses to the coarsest agent
With one identity, one grant set must cover the union of every sub-agent's needs: the read-only researcher inherits the executor's write access. Least privilege becomes most privilege with extra steps.
Prompt injection inherits everything
A steered sub-agent can attempt anything the shared identity permits — including the tools that only a different sub-agent was supposed to need. Blast radius is the union, not the role.
[ WHAT ROUTING IDENTITY LOOKS LIKE ]
Register each sub-agent role as its own identity with its own credential. The orchestrator holds a mapping from sub-agent to credential and attaches the acting sub-agent's token to each MCP call it forwards. Policy then reads naturally, per role — this is AI agent runtime governance applied inside the orchestration boundary, not just at its edge:
# Per-sub-agent policy: identity is the subject of every rule.
- id: researcher-reads
agent: orch-researcher
server: github
tool: [read_file, search_code]
action: permit
- id: writer-drafts
agent: orch-writer
server: github
tool: [create_branch, create_pull_request]
action: permit
- id: executor-gated
agent: orch-executor
server: github
tool: merge_pull_request
when: { branch: main }
action: require_approval
# The orchestrator's own identity is scoped to orchestration —
# it holds none of its workers' grants.
- id: default-deny
agent: "*"
server: "*"
tool: "*"
action: blockThree roles, three blast radii. A steered researcher can read; it cannot merge.
The audit trail now answers the question that matters: not "did the orchestrator do something" — it always did — but which role attempted what, under which rule. And for MCP servers you control, verifying the agent token inside the server closes the last gap: an internal code path that connects directly, skipping the proxy, still has to present an identity or is refused.
[ BEST PRACTICES ]
- ◈One registered identity per sub-agent role, from day one. Renaming and splitting identities later doesn't repair a history logged under one name.
- ◈The orchestrator attaches the acting sub-agent's credential to each call it forwards — it routes identity; it never substitutes its own.
- ◈Give the orchestrator its own identity too, scoped to orchestration (spawning, scheduling, aggregation) — not the union of its workers' permissions.
- ◈Write policy per sub-agent role: the researcher's grants are read-shaped, the executor's writes go through approval gates, and neither can use the other's tools.
- ◈If you own the downstream MCP server, verify agent tokens in the server as well — then an internal code path that skips the proxy still cannot skip identity.
- ◈Review the identity roster against observed callers on a schedule; a sub-agent someone added quickly and pointed at the proxy unregistered is exactly what ghost-style detection exists to surface.
The deeper principle: orchestrators dispatch tasks and identity together. The moment those two travel separately, attribution is being destroyed somewhere.
[ HOW SENTNELOPS IMPLEMENTS THIS ]
[ FREQUENTLY ASKED QUESTIONS ]
Can a multi-agent orchestrator be governed with a single identity?
Partially, and the gap is permanent. Per-call detail (tool, parameters, decision) is still recorded, and policy can still constrain servers, tools, and parameters. What is lost is attribution and per-role privilege: every action reads as the orchestrator, and every sub-agent operates with the union of all grants. Both losses happen at call time and cannot be reconstructed afterwards.
What does it mean for an orchestrator to be an identity router?
It means each call the orchestrator forwards carries the credential of the sub-agent on whose behalf it acts, rather than the orchestrator's own. The orchestrator moves identity through the system the way it moves tasks — it dispatches both, and absorbs neither.
Do sub-agents inside one process really need separate identities?
If they have different jobs, yes. Identity in agent systems tracks roles and their permissions, not processes. Two sub-agents in one process with different tool needs are two actors; giving them one identity merges their blast radii and their audit trails.
How does per-sub-agent policy work with conditional rules?
The same way as for any agent: rules are keyed by the presented identity, so each sub-agent gets its own permit, block, and require_approval rules, including parameter and environment conditions. In SentnelOps, policies stay plain YAML; conditional logic is compiled to an internal engine, and the decision plus the matched rule are logged per call.
What stops an internal agent from connecting to the MCP server directly and skipping all of this?
Two controls. Network placement: allow MCP servers to accept traffic only from the enforcement proxy, so a direct connection is refused at the network layer. Server-side verification: if you own the server, validate agent tokens inside it, so even a permitted network path still requires a presented identity.