The Intent-Governance Model: Governing by Declared Intent Rather Than Enumerated Permissions

A permission model answers one question with precision: may this principal touch this resource? It is silent on a second question that matters just as much for an autonomous agent: should it, given what it was actually asked to do? The two come apart the moment an agent stops behaving as intended. A hijacked agent, or one whose goal has quietly drifted, does not need to break any permission to cause harm — it spends the authority it legitimately holds on actions nobody wanted. Enumerated permissions cannot catch this, because from their point of view nothing is wrong. Intent-based governance is the response: authorize the agent against an explicit declaration of what it is trying to accomplish, and judge each action by whether it serves that declared intent. This article builds that model from first principles, sets it beside access control, and is honest about the gap between a declared intent and a true one.

The Limits of Enumerated Permissions

Access control is the discipline of deciding whether a principal — an entity that can be authenticated — may perform an action on a resource. In its dominant forms it is enumerative: a policy lists the resources a principal may touch and the operations it may perform, and a request is allowed if it matches an entry. This is powerful and necessary, and modern practice sharpens it further; the zero-trust architecture of NIST SP 800-207 insists that every request be authenticated and authorized on its own merits rather than trusted by network position.

But enumeration encodes capability, not purpose. A permission says an agent may call a payments API; it cannot say the agent may do so only in service of the reimbursement task it was given. The distinction is invisible while the agent behaves as intended, because intended actions are a subset of permitted ones. It becomes decisive the moment behavior diverges: an agent whose goal has drifted, or one steered by an instruction injected into the data it processed, issues actions that are individually permitted and collectively wrong. The OWASP Agentic Security Initiative names this class directly, describing excessive agency and the harm an agent can do wielding authority it holds but should not be exercising.

The gap is structural, not a matter of tightening the permission list. You could narrow permissions until they barely cover the intended task, but you cannot narrow them to purpose, because purpose is not a property of the resource — it is a property of why the action is being taken. Two identical API calls, byte for byte, can be one legitimate and one an abuse, distinguished only by the goal they serve. Enumerated permissions, evaluating the call in isolation, cannot tell them apart. Something has to carry the 'why'.

What Intent-Based Governance Is

Intent-based governance is the practice of authorizing an agent against a declared intent and evaluating each action by whether it serves that intent. A declared intent is a machine-checkable statement, fixed before or at the start of a task, of what the agent is to accomplish, under what constraints, and within what scope. The governance decision is no longer only 'is this action permitted?' but the conjunction 'is this action permitted AND does it serve the declared intent AND does it respect the declared constraints?'

The model has a precedent in how regulation is beginning to frame AI. The EU AI Act organizes obligations around a system's intended purpose — the use for which a system is provided as declared by its provider — making the declared purpose, not merely the technical capability, the anchor for what is and isn't acceptable. Intent-based governance imports that stance into the runtime: the agent's declared intent is the anchor against which its concrete actions are judged, moment to moment. It is the operational counterpart to a regulatory idea, brought down to the level of individual tool calls.

Two clarifications keep the model honest. First, 'intent' here is the declared, machine-readable artifact, not the agent's inner mental state — governance can only act on what is written down and checkable. Second, intent-based governance is additive: it presupposes access control beneath it and adds the purpose layer on top. An action that serves the declared intent but exceeds the agent's permissions must still be denied; intent authorizes nothing that permissions forbid. The model narrows the permitted set to the intended subset — it never widens it.

The Anatomy of a Declared Intent

For intent to govern, it must be structured enough to check an action against. A useful declared intent has four parts. The goal states, positively, what the agent is to achieve — the objective the task exists to serve. The constraints state the non-negotiable boundaries that hold regardless of the goal: things the agent must not do even in pursuit of the objective. The scope bounds the resources, data, and actions the task legitimately involves, so that anything outside it is presumptively off-intent. And the provenance records who declared this intent and how, so that the intent itself can be trusted rather than assumed.

These parts do different jobs, and conflating them weakens governance. The goal is a positive target and is inherently soft — an action can serve it more or less well. Constraints are hard predicates, closer in spirit to invariants: an action either violates one or it does not, and a violation is decisive regardless of how well the action serves the goal. Scope is the middle term that makes 'off-intent' concrete: without a declared scope, judging whether an action belongs to the task is a matter of opinion; with one, it is a membership test. Provenance is what stops the whole scheme from being circular — an intent an adversary can forge or silently rewrite governs nothing.

This structure connects to the governance functions the NIST AI Risk Management Framework describes, where mapping a system's context and intended use is foundational to managing its risk. A declared intent is the runtime, per-task instantiation of that mapping: goal, constraints, and scope are exactly the context an action must be judged against, made concrete enough for a machine to evaluate rather than left as prose in a design document.

How Intent Governs an Action

With a structured intent in hand, governing an action becomes a short, ordered decision. First, is the action permitted at all by access control? If not, it is denied and intent never enters the picture — permissions remain the hard floor. If it is permitted, does it violate any declared constraint? A constraint violation is a hard denial regardless of goal-service, because constraints are the non-negotiable boundaries. If no constraint is violated, is the action within the declared scope? An out-of-scope action is presumptively off-intent and denied or escalated. Only an action that is permitted, constraint-respecting, in-scope, and plausibly goal-serving is allowed.

The ordering matters because it puts the cheapest and most decisive checks first and reserves the hardest judgment for last. Permission and constraint checks are crisp predicates — fast and unambiguous. Scope is a membership test against the declared resources. Goal-service is the only genuinely graded judgment, asking whether the action plausibly advances the declared objective, and because it is graded it is where governance is hardest and where a conformance signal, not a boolean, is the honest output. Placing it last means most off-intent actions are caught by a crisp earlier check before the fuzzy one is even needed.

This is per-action governance, evaluated moment to moment, which aligns it naturally with the zero-trust posture of evaluating every request on its own merits. The difference is the criterion: zero-trust asks whether the request is authenticated and authorized; intent-based governance adds whether it is on-purpose. The two compose into a single gate an action must pass — identity and permission from below, declared intent from above.

The Intent-Action Gap

The central difficulty of the whole model is that a declared intent is a proxy for the true purpose, and the distance between them is where undetected harm lives. This is the intent-action gap: governance can only judge an action against the intent as declared, so it is structurally blind along any dimension the declaration fails to encode. If the true purpose forbids something the declared constraints never mention, an agent can pursue it while every check passes, because the check has nothing to compare against.

The gap has the same shape as the proxy-target problem that pervades machine learning, where optimizing a measurable stand-in for a true objective drifts away from that objective precisely where the stand-in is silent. Here the declared intent is the measurable stand-in for what the operator actually wants, and the governance is only ever as good as that stand-in's coverage. This is not a reason to abandon the model — a partial 'why' is enormously better than none — but it is a reason to treat the declared intent as a first-class artifact whose coverage is measured, red-teamed for blind spots, and versioned, rather than assumed complete.

It also sets the agenda for everything that a full intent-governance practice must add. Because the declaration can be incomplete, you need a disciplined way to capture and verify intent so its coverage is known. Because a compiled guardrail can fail open where the intent is silent, you need to know where enforcement degrades. Because goal-service is graded, you need to measure conformance rather than assert it. And because intents accumulate across a fleet, you need ledgers and audit trails so the whole system's intents are inspectable. Each is a response to the same gap, attacked from a different side.

Composing with Access Control

Intent-based governance is best understood as a layer that sits above access control, not a replacement for it. At the base is identity — establishing which principal is acting. Above it is access control — establishing what that principal may do. Above that is intent-based governance — establishing whether a permitted action is on-purpose. Each layer is necessary and none is sufficient alone: identity without permissions grants nothing meaningful, permissions without intent cannot catch on-permission abuse, and intent without permissions would be an unenforceable wish.

Stacking them clarifies where each control's guarantee comes from and where it stops. Identity guarantees you know who is acting and can revoke them. Access control guarantees an action is within capability. Intent-based governance guarantees an action is within declared purpose — to the extent the declaration is complete. The composition also makes the failure modes separable: an on-purpose action denied by permissions is a permission problem to fix at that layer; a permitted action denied by intent is a purpose mismatch to resolve at this one. Keeping the layers distinct is what lets each be reasoned about, and audited, on its own terms.

The layered view also positions intent-based governance within the management-system framing that standards like ISO/IEC 42001 encourage, where an organization defines objectives and controls for its AI systems and demonstrates they are met. Declared intents are the per-task, machine-checkable expression of those objectives, and the governance decisions they drive are the evidence that the objectives are being honored at runtime rather than only on paper.

Limitations and Threats to Validity

This article presents a model and its structure, not an empirical evaluation, and its claims should be read accordingly. The central limitation is the intent-action gap itself: the model's protection is bounded by how faithfully a true purpose can be reduced to a declared goal, constraints, and scope, and some purposes resist that reduction. A declaration rich enough to govern a complex, open-ended task may be as hard to get right as the task, and an under-specified declaration governs little. The honest posture is that intent-based governance raises the floor — it catches the large class of on-permission actions that plainly serve no declared purpose — without promising to catch every subtle divergence.

There are two further dependencies worth naming. The model assumes intent can be captured with trustworthy provenance; if an adversary can forge or silently alter the declared intent, the governance built on it is not just weakened but inverted, because the attacker now writes the standard the actions are judged against. And it assumes goal-service can be evaluated at all — an assumption that pushes work onto conformance measurement, which is itself imperfect and can be gamed by actions engineered to look on-purpose. None of this defeats the model; all of it says the same thing the gap does. Intent-based governance is a necessary addition that supplies the missing 'why', and its real-world value is exactly the fidelity of the intent it is given and the rigor of the conformance it can measure.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

intent:
  goal: "reconcile the March vendor invoices"   # positive objective (soft)
  constraints:                                    # hard — violation denies
    - never: send_external_communication
    - never: modify_records_before: 2026-03-01
  scope:                                          # in-task resources only
    resources: [ invoices/2026-03/*, ledger:march ]
    actions:   [ read, match, annotate ]
  provenance:
    declared_by: reconciliation-service
    signed: true                                  # cannot be forged/rewritten
decision: permitted AND serves(goal) AND within(constraints, scope)

Glossary

Access control

The discipline of deciding whether an authenticated principal may perform an action on a resource; in dominant forms it enumerates permitted resources and operations.

Declared intent

A machine-checkable statement, fixed before or at task start, of the goal the agent is to achieve, its constraints, its scope, and its provenance.

Intent-based governance

Authorizing an agent against a declared intent and evaluating each action by whether it serves that intent, layered above access control.

Goal

The positive objective a declared intent states; inherently soft, since an action can serve it more or less well.

Constraint

A non-negotiable boundary in a declared intent that holds regardless of the goal; a hard predicate whose violation is decisive.

Scope

The resources, data, and actions a task legitimately involves; anything outside it is presumptively off-intent.

Intent-action gap

The distance between a declared intent and the true purpose, along which governance is structurally blind.

Intended purpose

In the EU AI Act, the use for which a system is provided as declared by its provider — a regulatory anchor analogous to declared intent.

References

1. NIST AI 100-1, AI Risk Management Framework (AI RMF 1.0)
2. NIST AI 600-1, Generative AI Profile (2024)
3. NIST SP 800-207, Zero Trust Architecture (2020)
4. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
5. OWASP Top 10 for LLM Applications (2025)
6. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)
7. ISO/IEC 42001:2023, AI Management System (AIMS)
8. Regulation (EU) 2024/1689, the EU Artificial Intelligence Act (2024)