AI Agents Don't Have Badges
TL;DR: Every major IGA platform was built when "identity" meant a person with a badge. AI agents don't have badges. They have tool grants, MCP delegations, and autonomous decision-making. Governing them requires a new primitive — runtime authorization at the protocol level, immutable safety invariants, and prompt injection gates — not a service-account template with a longer description field.
The identity explosion
In 2024, non-human identities outnumbered humans roughly 3:1 in the average enterprise. Service accounts, API keys, CI/CD tokens, cloud workload identities. That ratio was already uncomfortable. IGA vendors handled it the way they handle everything: they added a new identity type to the dropdown and called it solved.
In 2026, AI agents are pushing that ratio past 10:1. Not because enterprises are creating ten times more service accounts, but because every deployed agent spawns sub-agents, claims tool grants, opens MCP sessions, and operates with delegated authority that compounds through chains no human explicitly approved.
This is not the same problem at a larger scale. It is a different problem.
Why agents are not service accounts
A service account is a static credential with a fixed set of permissions. It does what code tells it to do. When it accesses a database, the access pattern is deterministic — the same query, the same scope, the same blast radius, every time. You can review it in a PR. You can audit it annually. Traditional IGA handles this reasonably well.
An AI agent is fundamentally different in three ways that break the service-account model:
1. Agents make decisions. A service account executes a function. An agent decides which function to call, with what parameters, in what sequence. The decision space is unbounded at deploy time. You cannot review "what this agent will do" in a pull request, because it hasn't decided yet.
2. Agents compose tool calls. An agent with read access to a customer database and write access to an email service can decide — on its own — to extract customer data and email it externally. Neither permission is dangerous alone. The composition is. Traditional IGA evaluates permissions individually. Nobody is evaluating the combinatorial blast radius of an agent's full tool set in real time.
3. Agents can escalate their own privileges. If an agent has access to an IAM API, a Terraform provider, or even a well-crafted MCP tool, it can request additional permissions, create new credentials, or spawn sub-agents with broader scope. Without protocol-level constraints, the agent's effective permission set is not what you granted — it's whatever it can reach through the transitive closure of its tool graph.
This is why retrofitting a service-account governance model onto AI agents is not conservative engineering. It is negligent engineering. The threat model is categorically different.
What runtime governance looks like
If you accept that agents are not service accounts, three requirements follow:
Authorization must happen at the tool-call level, not at the identity level. Granting an agent a role is insufficient. Every tool invocation — every MCP call, every API request, every sub-agent spawn — needs to be evaluated against policy in real time, with the full context of what the agent has already done in this session. This is not a feature you bolt onto an existing RBAC engine. It requires a policy evaluation architecture designed for per-call latency at agent-interaction speed.
Safety invariants must be immutable. Configurable policy is necessary for tenant-specific rules. But the rules that prevent catastrophic outcomes — no external data exfiltration, no self-modification of permissions, no agent creation without a human owner — cannot be runtime-configurable. If an admin can disable them, an attacker who compromises the admin can disable them. These invariants need to be cryptographically signed, verified at startup, and unreachable by any API. We call this a Machine Constitution.
Prompt injection must be stopped before the LLM. An AI agent that processes untrusted input — and nearly all of them do — is vulnerable to prompt injection attacks that can override its instructions and abuse its tool grants. Governing the agent's permissions is meaningless if an attacker can hijack the agent's intent. The injection gate must sit in front of the LLM, not after it.
What SidantiX ships today
I spent years building identity governance for humans. When I started SidantiX, I made a deliberate choice: build for the agent era from day one, not retrofit later.
Here is what is in production:
- MCP tool-call authorization. Every MCP tool invocation passes through our policy engine before execution. Policy evaluates the agent's identity, the target tool, the call parameters, the session history, and the agent's full tool graph. Sub-millisecond. Per call.
- Machine Constitution. A cryptographically signed, runtime-immutable rule set that sits above all configurable policy. Ed25519-signed. Verified at startup. No API to modify, disable, or bypass. Open spec, MIT license.
- Prompt injection gate. Inbound prompts are classified and blocked before they reach the LLM. The gate operates on the raw input, not on the model's interpretation of it. Attacks are stopped pre-inference.
- EU AI Act Article 9 conformity module. Risk classification, human oversight controls, and audit evidence generation aligned to the Act's requirements for high-risk AI systems. Not a checklist — a runtime enforcement layer with cryptographic evidence.
This is not a roadmap. It is shipping code, in production, with evidence packs you can verify offline.
The ask
If you are evaluating IGA platforms for an environment that includes AI agents — and by 2027 that will be every environment — ask your vendor four questions:
- Do you authorize at the tool-call level, or at the identity level?
- Are your safety rules runtime-immutable, or can an admin disable them?
- Where is your prompt injection gate — before the LLM, or after?
- Can you hand me a cryptographic evidence pack for last Tuesday's agent decisions?
If the answer to any of these is "we're working on it," you are looking at a platform that was built for badge-holders and is being retrofitted for agents. That retrofit will always be one step behind, because the architecture was never designed for the problem.
We built SidantiX for this problem from the first line of code.