Capturing and Verifying Intent: Intent Specs, Provenance, and the Intent-Action Gap

An intent-based governance system is only as good as the intent it is given, and an intent is not a natural object — it is something a person or process has to produce, deliberately, before it can govern anything. That production has three failure points, each distinct. The intent might be captured badly, reducing a rich purpose to a specification too thin to catch real divergence. It might be captured well but left unprotected, so that an attacker can quietly rewrite it and thereby rewrite the very standard the agent's actions are measured against. Or it might be captured faithfully and secured perfectly, yet still be silently incomplete, blind to some dimension of the true purpose that no one thought to encode. This article takes each in turn: how intent is captured into a specification, how its provenance is verified so it can be trusted, and how the gap between the specification and the true purpose is measured rather than wished away.

From Prose to Specification

Intent begins as prose — a human wanting an agent to accomplish something, expressed in natural language or implied by a request. Prose cannot govern an action, because governing requires comparing a concrete action against the intent mechanically, and prose is not mechanically comparable. Capture is the process of reducing that prose to an intent specification: a structured, machine-checkable artifact stating the goal, the constraints, and the scope precisely enough that a governance layer can evaluate an action against it.

The reduction is a pipeline with a verification step at its end. A source purpose — a request, a task assignment, a policy — is parsed into a candidate specification; the candidate is checked for well-formedness and internal consistency; and only a validated specification is admitted to govern. Skipping the validation is the common mistake: a specification that contradicts itself, or that leaves a constraint ambiguous, will produce governance decisions that are arbitrary exactly where they matter most. The NIST AI Risk Management Framework's emphasis on mapping a system's intended use is the design-time analogue of this; capture is that mapping performed per task, in a form a machine can act on.

Capture is inherently lossy, and acknowledging the loss is part of doing it well. Some of a purpose survives the reduction cleanly — a hard prohibition becomes a hard constraint with no ambiguity. Some survives only approximately — a nuanced objective becomes a goal statement that a conformance signal can score but never perfectly capture. And some may not survive at all, which is precisely the material that later becomes the intent-action gap. A disciplined capture process records what it could not encode, rather than presenting the specification as if it were the whole purpose.

What Makes a Specification Checkable

For a specification to govern, each part must be expressed in a form an action can be tested against, and the forms differ by part. A constraint should be a decidable predicate over an action and its context — given a proposed action, the predicate returns violated or not, with no judgment call. Scope should be a membership condition — the resources and action types the task legitimately involves, so that belonging is a test rather than an opinion. The goal is the hard case: it cannot be a boolean, because service is graded, so it is captured as a description against which a conformance signal can score an action's alignment.

This split determines how much of governance is crisp versus fuzzy, and good capture pushes as much as possible toward the crisp side. Anything that can be expressed as a hard constraint should be, because hard constraints are unambiguous and cheap to enforce. Reserving the fuzzy goal-conformance judgment for what genuinely cannot be made crisp keeps the uncertain part of governance small. A specification that leans on goal-conformance for something that could have been a flat prohibition has simply moved a decidable check into an undecidable one, and weakened itself for no reason.

Well-formedness also means the parts do not contradict each other. A constraint that forbids what the goal requires makes the specification unsatisfiable, and a scope that excludes resources the goal needs makes it unachievable. Validation catches these before the specification governs anything, because a self-contradictory intent does not fail safe — it fails arbitrarily, allowing or denying depending on evaluation order rather than principle.

Provenance: Trusting the Intent Itself

A subtle and dangerous property of intent-based governance is that the intent is the standard. If an adversary can alter the declared intent, they do not merely evade governance — they commandeer it, because now the agent's actions are judged against a standard the attacker wrote. This inverts the whole control: a governance layer faithfully enforcing a forged intent will happily permit exactly the actions the attacker wants. Provenance is the defense, and it is not optional.

Provenance is the verifiable record of who declared an intent and that it has not been altered since. Concretely, an intent specification is signed by the authority entitled to declare it, and the governance layer verifies that signature before admitting the specification and on every use. This makes tampering detectable and forgery infeasible without the declaring authority's key. The threat this closes is live and specific: the OWASP guidance on prompt injection describes how instructions smuggled through data an agent processes can redirect its behavior, and an intent whose provenance is unverified is exactly the channel such an injection would target — rewrite the goal, relax a constraint, widen the scope, and the injected purpose becomes the governed one.

Provenance must cover the whole life of the intent, not just its birth. An intent captured with a signature but then cached, transported, or amended without re-verification reopens the hole in the middle. The discipline is to treat the signed specification as the only thing the governance layer will act on, to re-verify it at each use rather than trusting a prior check, and to require any amendment to be a freshly signed specification from the declaring authority. An intent that can be edited in flight is an intent an attacker can edit in flight.

The Intent-Action Gap, Made Visible

Even a faithfully captured, perfectly signed intent is a proxy for the true purpose, and the region the proxy fails to cover is where governance is blind. Picture two sets: the true purpose — everything the operator actually wants and forbids — and the declared intent — everything the specification encodes. Where they overlap, governance works: an action is judged against a standard that matches reality. Outside the overlap live two hazards. There is true purpose the intent never captured, where a harmful action passes every check because no check exists for it. And there is declared intent that overreaches the true purpose, where governance may block or escalate legitimate actions the operator would have allowed.

Naming the gap this way turns an abstract worry into a measurable quantity. The relevant question is not 'is the intent complete?' — it never is — but 'how large is the uncovered region, and along which dimensions?' That is answerable by comparing the specification's coverage against an enumeration of the purpose's dimensions: the kinds of actions, resources, and outcomes the task can involve, and for each, whether the specification says anything. Dimensions the specification is silent on are the gap, and they are exactly where governance provides no protection.

This is the same proxy-target separation that recurs throughout machine learning, where a measurable stand-in for a true objective diverges from it precisely where the stand-in is silent. The response is not to abandon the proxy but to know its edges. A governance layer that reports 'this action is on-intent' should be understood as reporting 'on-intent with respect to the dimensions the specification covers' — and the honest deployment publishes what those dimensions are, so a false sense of total coverage never sets in.

Verifying Coverage by Red-Teaming the Spec

Measuring the gap requires actively probing for it, because blind spots do not announce themselves. The method is to red-team the specification: enumerate the ways a task could be pursued that a reasonable operator would object to, and for each, check whether the specification actually catches it. A harmful action the specification permits is a covered dimension the specification missed — a concrete, fixable blind spot. This is adversarial thinking applied not to the agent but to the intent that governs it, and it is the only reliable way to find where the proxy is silent before an adversary does.

The probing is disciplined, not ad hoc. Start from the task's dimensions — the resources it touches, the action types it can take, the outcomes it can produce — and for each dimension ask what an abuse along it would look like and whether a constraint or scope rule would stop it. Frameworks that catalog adversarial techniques against AI systems, such as MITRE ATLAS, are a source of dimensions worth probing, since a technique that exists against AI systems generally is a technique an under-specified intent might fail to forbid. Each probe either confirms coverage or surfaces a gap to close by adding a constraint, tightening scope, or explicitly accepting the risk.

The output of red-teaming is not a pass/fail but a coverage map: for each dimension, whether the specification governs it, and if not, whether that gap is an accepted risk or an outstanding one. This map is what makes governance honest. It converts 'we govern by intent' into 'we govern these dimensions by intent, and we know these others are uncovered', which is a claim a reviewer, an auditor, or a regulator can actually assess.

Intent as a Versioned Artifact

Because a specification is captured, signed, and coverage-mapped, it is a build artifact, and it should be treated like one: versioned, with its provenance and its known limitations recorded alongside it. A version identifies exactly which specification governed a given period, so that a governance decision can always be traced to the intent that produced it. Without versioning, an audit of why an action was allowed or denied has no fixed standard to appeal to, because the intent may have changed since.

Versioning also makes the specification improvable without losing accountability. When red-teaming surfaces a blind spot, the fix is a new version that adds the missing constraint, signed afresh and recording what changed and why. The old version remains part of the record — it is what governed before the fix — so the history of the intent is auditable, and a regression is detectable. This is the same discipline that management-system standards like ISO/IEC 42001 encourage for AI controls generally: not a one-time declaration but a maintained, evidenced artifact that demonstrates the intended controls are actually in force and evolving as understanding improves.

Versioning finally ties capture and verification back to governance. The signed, versioned, coverage-mapped specification is precisely the object the governance layer evaluates actions against, and everything in this treatment exists to make that object trustworthy: capture makes it faithful, provenance makes it authentic, coverage measurement makes it honest, and versioning makes it accountable. An intent that is all four is one governance can actually rely on. An intent missing any one is a standard that is either wrong, forgeable, blind, or untraceable.

Limitations and Threats to Validity

This article describes a method for capturing and verifying intent, not an empirical evaluation of one, and its guarantees are the conditional kind. The reduction from prose to specification is fundamentally lossy, and there is no procedure that guarantees a complete capture of an open-ended purpose; the coverage map bounds the loss but does not eliminate it, and a purpose too rich to specify will govern only partially no matter how careful the process. Red-teaming, likewise, finds the blind spots it thinks to probe for — a dimension no one imagined an abuse along will pass unexamined, so the coverage map is itself a proxy with its own edges.

Two dependencies deserve emphasis. Provenance rests on key management: if the declaring authority's signing key is compromised, the attacker can produce authentic-looking intents and the inversion this section warned about happens with full cryptographic blessing, so the security of the whole scheme reduces in part to the security of that key. And goal-conformance capture pushes hard work downstream onto measurement, which is imperfect and can be gamed by actions engineered to look aligned. None of this undermines the value of capturing and verifying intent; it locates that value precisely. A declared intent supplies the missing 'why' that permissions cannot, and its worth in practice is the fidelity of its capture, the integrity of its provenance, and the honesty of its measured coverage — no more, and no less.

Practitioner Toolkit

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

admit_intent(spec):
  require: verify_signature(spec, declaring_authority_key)   # authentic
  require: spec.version is not None                          # accountable
  require: validate_wellformed(spec)                         # faithful
  on_each_use:
    re_verify_signature(spec)          # never trust a prior check
    reject_if amended_since_signed(spec)
  attach: coverage_map(spec)           # honest — governed dimensions known
  deny_if: signature_invalid OR unsigned OR edited_in_flight

Glossary

Capture

The process of reducing a prose purpose to a machine-checkable intent specification of goal, constraints, and scope.

Intent specification

A structured, validated artifact stating a task's goal, constraints, and scope precisely enough for a governance layer to evaluate actions against.

Decidable predicate

A test over an action and its context that returns a definite violated-or-not answer with no judgment call, the ideal form for a constraint.

Provenance

The verifiable record of who declared an intent and that it has not been altered since, established by signing and re-verified at each use.

Intent-action gap

The region of the true purpose that the declared intent fails to encode, along which governance provides no protection.

Coverage map

A per-dimension record of which parts of a task's purpose the specification governs and which are accepted or outstanding gaps.

Red-teaming the spec

Adversarially probing an intent specification for abuses it permits, to surface blind spots before an attacker does.

Versioned intent

A signed specification identified by version, with its provenance and known limitations recorded, so governance decisions trace to a fixed standard.

References

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