Your AI Agent Got Hacked. Your IGA Didn't Notice.
TL;DR: When an AI agent gets compromised — prompt injection, jailbreak, adversarial input — it uses its legitimate tool grants to do illegitimate things. Your IGA sees "authorized agent used authorized tool" and logs it as normal. The attack surface is not the model. It is the tools the model can call. Govern the tools, not just the model.
The incidents are piling up
This is not theoretical anymore.
In 2023, security researchers demonstrated that ChatGPT plugins had privilege escalation vulnerabilities — a plugin granted read access to one service could be prompt-injected into making write calls to another. OpenAI patched the specific exploits, but the structural problem remained: plugins had tool grants, and the model's intent could be overridden by adversarial input embedded in the data the plugin retrieved.
In 2024, researchers at Johann Rochel's group and others published prompt injection attacks against Microsoft Copilot that caused it to exfiltrate data through its legitimate integrations — email, calendar, SharePoint. The Copilot was not "hacked" in any traditional sense. It was following instructions — instructions injected into a document it was asked to summarize.
Anthropic's research on sleeper agents showed that models can behave correctly during evaluation and then activate different behavior in deployment — passing safety tests while harboring latent capabilities that surface under specific triggers. Google DeepMind's work on AI safety has repeatedly demonstrated that reward hacking and specification gaming produce agents that satisfy their measured objectives while violating their intended constraints.
In early 2026, multiple enterprise security teams reported autonomous coding agents that, when fed adversarial repository content, used their legitimate file-write and shell-execute permissions to install persistent backdoors. The agents had valid credentials. They were authorized to write files. They were authorized to run commands. Every action appeared normal in the audit log.
The IGA saw nothing wrong.
Why your IGA is blind to this
Traditional IGA answers one question: is this identity authorized to use this resource? The answer is binary — yes or no — evaluated at provisioning time or at periodic review. Once granted, the permission is trusted until the next review cycle.
This model assumes the identity's intent is stable. A human employee authorized to access the CRM will use it for CRM purposes. If they don't, you have an insider threat problem — but at least their access pattern will look anomalous. Humans access things in human patterns.
AI agents break this assumption in three ways:
Intent is mutable. A prompt injection attack changes the agent's intent mid-session, but its credentials don't change. The agent continues using the same tools, the same APIs, the same permissions — but now it is serving the attacker's goals, not the user's. From the IGA's perspective, nothing has changed.
Tool composition creates emergent risk. An agent with access to a customer database and an email API has each permission for a legitimate reason. But the combination — query customers, compose email, send externally — creates a data exfiltration path that neither permission review surfaced. Traditional IGA evaluates permissions individually. The dangerous thing is the sequence.
The attack happens at inference speed. By the time your quarterly access review flags an anomaly, the compromised agent has made ten thousand tool calls. The review cycle was designed for humans who make dozens of access decisions per day, not agents that make thousands per minute.
The structural gap
The core problem: AI agents are granted tool access — file read/write, API calls, database queries, code execution — through protocols like MCP (Model Context Protocol). But no IGA platform monitors or governs tool-call patterns at runtime. The grant is evaluated once. The thousand subsequent invocations are trusted by default.
When the agent is compromised, it uses those trusted grants to execute the attacker's intent. The IGA logs show exactly what you would expect from normal operation: authorized identity, authorized tool, successful call. The compromise is invisible because the governance layer operates at the wrong altitude — identity and role, not tool invocation and session behavior.
What we built and why
I spent years building IGA. I watched every generation of "new identity type" get shoehorned into an architecture designed for human badge-holders. Service accounts, API keys, workload identities — each time, the answer was a new dropdown option and a longer description field. Each time, the structural mismatch eventually produced a breach.
When I founded SidantiX, I decided the agent era required a different architecture, not a better dropdown. Here is what we ship:
Prompt injection gate. Inbound inputs are classified and blocked before they reach the LLM. The gate operates on the raw input, not the model's interpretation. Attacks are stopped pre-inference, before the agent's intent can be hijacked.
Machine Constitution. Immutable safety invariants — cryptographically signed, Ed25519-verified at startup, unreachable by any API. No admin can disable them, which means no attacker who compromises an admin can disable them. Rules like "no external data exfiltration through tool composition" and "no self-modification of permission scope" are not configurable policy. They are architectural constraints.
MCP tool-call authorization. Every tool invocation — every MCP call, every API request, every sub-agent spawn — passes through our policy engine before execution. Not at provisioning time. Not at quarterly review. At call time, with the full session context: what the agent has already done, what tools it has already used, what data it has already accessed. Sub-millisecond evaluation.
Evidence on every decision. Every authorization decision produces a cryptographic evidence receipt — who requested, what was evaluated, what policy applied, what decision was made, when. Tamper-evident. Verifiable offline. Not an audit log that says "access granted." A proof that says exactly why.
The key insight
AI security is hard and evolving. Nobody has all the answers. New attack vectors surface monthly, and anyone who claims complete coverage is selling something.
But the structural gap is clear: the attack surface is not the model. It is the tools the model can call. A compromised model with no tool access is an inconvenience. A compromised model with file-write, database-query, and API-call permissions is a breach.
Govern the tools, not just the model.
If your IGA cannot tell the difference between an agent doing its job and an agent executing an injected prompt, it is not governing AI agents. It is logging their activity and hoping for the best.