Intent as a Security Boundary
The missing control layer isn't more access management. It's purpose.
This is the fourth essay in Authority as the Control Plane, a series on authority, identity, and control in AI-driven systems.
An agent with valid credentials, correct permissions, and a legitimate task can be redirected mid-execution by the content it processes, and nothing in the current enterprise control stack will catch it. That’s why indirect prompt injection made the OWASP Top 10 for LLM applications.
Security engineers who push back on intent governance usually have a reasonable objection ready: “We have ABAC. We have Zero Trust. What is intent governance doing that those don’t?”
It’s the right question. And the answer isn’t that ABAC is wrong. It’s that ABAC governs a moment while intent governance governs a trajectory, and most enterprises are only now discovering how far apart those two things sit.
That evaluation layer doesn’t exist yet in most organizations. Building it is what this article is about.
What Intent Actually Is
Intent gets treated like a soft concept in security conversations, something philosophical and unprovable that sits outside the scope of what a control system can reason about.
I’ve been in enough post-incident reviews to know this framing is wrong, and in agentic systems it’s the framing that gets organizations into trouble.
In human-driven systems, intent lives inside someone’s head. It’s invisible to the infrastructure, so the infrastructure was never built to ingest it. That was a reasonable design constraint at the time. AI-driven systems don’t share it.
When an agent operates, intent is encoded. It exists in the system prompt, the workflow definition, the instruction chain, the declared task objective, the API call sequence. Intent in an agentic system isn’t implicit the way it is with humans. It’s expressed in the artifacts the agent runs on, which means it can be compared, evaluated, and enforced. That is what makes it governable.
Intent answers a question no access control system currently asks: Why is this action being taken, and does the scope of this execution match the scope of this task?
A summarization agent has no legitimate need to write to the database it’s reading from. A procurement workflow has no business touching HR systems. The scope of execution should be bounded by the scope of intent. Right now, that boundary doesn’t exist in the enterprise control stack.
That absence is a design failure, not a policy gap.
Intent Has Three Layers, Not One
This is where the framework gets precise, and where the engineering criticism usually lands wrong.
The common objection goes something like this: “You can’t verify intent at runtime. Prompt injection corrupts the instruction chain. Any intent governance framework is one injection away from being bypassed.”
That objection is accurate about one layer of intent. It doesn’t hold across all three.
Intent in an agentic system has a three-layer structure:
Registered intent is what the workflow was authorized to do at design and deployment time. This lives in the workflow registry. It’s the declared scope at the moment of approval. It cannot be corrupted by a prompt injection unless the registration system itself is compromised, which is a categorically different and harder attack.
Declared intent is what the instruction chain claims it’s doing at runtime. This is the layer prompt injection corrupts. A malicious payload embedded in an external document can redirect the operating instructions of the agent mid-execution.
Executed scope is what the agent actually touched. The observable footprint. API calls made. Data read or written. Systems accessed.
Blast radius, precisely defined, is the delta between declared and executed scope. It’s measurable at runtime, not just auditable after the fact.
And here’s the counterintuitive point: prompt injection is not a refutation of intent governance. It’s the strongest argument for building intent governance in the first place. Without a registered baseline, you have no mechanism to know that injection occurred. The discrepancy between registered intent and declared intent at runtime is exactly how you detect it.
This isn’t moving the trust boundary up one layer. This is creating a layer that can detect when the layer below it has been compromised.
How Intent Gets Corrupted
Three patterns. Each one is a different failure mode. Each one is invisible to the current enterprise control stack.
Prompt injection as intent corruption. An agent executing a legitimate workflow ingests external content mid-task, a document, an API response, or a database record, that contains embedded instructions. The agent follows them. The declared task continues. The operating intent has been replaced. The permissions never changed. The session remained valid. Nothing flagged it.
For engineers: this is detectable if you model the expected tool call graph against the actual one. A data pipeline agent calling a write endpoint outside its declared read task is a security event, not a performance anomaly. The data exists. The question is whether anyone has decided to treat it as a security signal.
Social engineering as delegated intent poisoning. An actor with legitimate access provides instructions to an AI agent that redirect its execution toward unauthorized objectives. There’s no zero-day here and no sophisticated exploit. The agent is doing what it was told, by someone who was allowed to tell it things. Delegated intent is one of the least governed surfaces in enterprise AI deployments, and it’s being actively exploited in ways that don’t show up in traditional logs as anything anomalous.
Indirect prompt injection as intent drift. An agent doesn’t get a single clean instruction. It accumulates context across a long session: multiple documents, prior tool outputs, embedded payloads in retrieved content. Small deviations compound. The original purpose degrades incrementally. By the time the audit log is reviewed, no single step was wrong. The trajectory was. Drift detection as a security primitive would catch this. No current control framework is looking for it.
These aren’t theoretical attack vectors. They’re operating conditions for any enterprise that has deployed agents at meaningful scale.
What It Means to Enforce Intent
There are three of these concepts, and none of them is fully solved in any product today. I’ll say that directly because the honest framing matters here. These are governance primitives the field needs and they’re tractable engineering problems, but calling them deployed capabilities would be inaccurate.
Scope binding. The authority surface of an agent is constrained to the logical boundaries of its declared task at registration time. A summarization workflow operates within read access to the source material. A procurement agent operates within the systems required for that workflow. Scope binding is task-scoped token issuance taken seriously. Engineers can see the shape of this: policy-as-code, workflow-aware authorization, constrained delegation. The governance requirement is clear. The implementation is not trivial, but it’s tractable.
Drift detection. Deviation from declared intent is a security event, not a performance anomaly or a compliance issue to flag in the next quarterly review. It’s detectable at runtime. Operationally this looks like behavioral baseline modeling against the declared objective, measuring statistical divergence between the expected action sequence and the actual one. This is a class of anomaly that existing SIEM and UEBA tooling wasn’t designed to surface, because it requires intent as an input. Without intent registration, there’s no baseline to deviate from.
Purpose expiry. Authority shouldn’t persist beyond completion of the stated task. When intent is fulfilled, delegation expires, not because the session ended or the token TTL elapsed, but because the purpose itself is complete. This is a different authorization trigger than anything in the current identity stack. Ephemeral credential patterns exist. Task-completion triggers for revocation are buildable. The conceptual shift is treating purpose completion as an authorization event, not just session termination.
Why ABAC and Zero Trust Don’t Close This Gap
The critique from practitioners who’ve been around a while usually goes: “This sounds like attribute-based access control. Or just Zero Trust applied consistently. What’s actually new?”
It’s a fair challenge. And the answer isn’t that ABAC and Zero Trust are wrong. They’re solving a different problem.
ABAC governs attributes at the moment of access. It evaluates whether the request matches the policy. It’s a point-in-time evaluation against a defined permission structure. That model was designed for humans making discrete access requests, and it works for that.
Intent governance evaluates the trajectory of execution against a declared objective over time. It’s continuous. The unit of analysis isn’t the request. It’s the task. And the question isn’t whether this actor has permission to make this API call. It’s whether this API call serves the purpose this agent was authorized to pursue.
These are fundamentally different problems, one evaluated at a single point in time and the other across the full arc of execution. Current authorization architectures are request-scoped. ACP is task-scoped. That distinction is the whole argument.
Zero Trust assumes any action by an authenticated identity with valid permissions is permissible within scope. Intent governance says the scope itself may be misaligned with purpose, even when authentication and permissions are clean.
An agent with read access to a CRM system that exports every record into a spreadsheet would pass every Zero Trust check. Valid token, permitted scope, authenticated session. The one thing no system evaluated was whether the action matched its purpose.
The Architecture Didn’t Fail. It Was Never Built for This.
None of this is a failure of IAM, IGA, or PAM. Those tools were built for a world where humans were the primary actors, where the unit of work was a discrete transaction, and where intent was invisible to the infrastructure because the actors were people.
That world is changing. Agents don’t make discrete requests. They chain actions across sessions, across systems, across organizational boundaries. The purpose behind those chains is now encoded and expressible. And the distance between what the enterprise has built to govern access and what’s required to govern authority widens every time a new agent gets deployed.
Fixing this isn’t a configuration change or a policy update. It’s an architectural addition: a new layer in the control stack, above identity and below the application, that treats intent as a security primitive.
Authority = f(Identity, Permission, Intent, Context).
We’ve governed Identity and Permission for two decades. Intent has been sitting in the equation the whole time. We just never built the infrastructure to evaluate it.
That changes when organizations decide that purpose is a security input, not a philosophical aside.
Next: Context and the SOC’s Unsolvable Problem. Identity telemetry is abundant. Actionable authority intelligence is scarce. The gap between them has a cost.
Puneet Bhatnagar writes the Authority as Control Plane series on Substack. He has spent nearly two decades building and governing identity programs at enterprise scale, including as Global Head of IAM at a major asset manager.