Theme Name

Intent-based security policies: expression, coexistence, and runtime verification

Proposer(s)

Cyril Gorlla (CTGT). Builds on candidate theme 2 from the 29 July preparation meeting; co-development welcome, particularly from the IETF and access-control side.

Appraisal checks and starter vector set (AVS-0.1, 2 September 2026; revised as AVS-0.2, 4 September 2026) contributed into task 3 by @tyche-dev, Tyche Institute, under his name.

Summary

Classical access control binds rights to a verified identity, but a verified identity says little about how an agent will behave on a given task, and revoking an identity does not reliably stop unwanted behavior. Deployment adds a sharper version of the problem: an agent that passes every identity and authorization check can still produce an output that violates the very policy it was authorized under. This theme explores expressing security policy as intent, properties that must hold regardless of which actor is involved, and extends the July 29 scope with a third question: how a relying party verifies, at the moment of action, that an agent's behavior conforms to the intent, and what verdict that verification produces. Discussion on #1 and #5 has refined when a requirement binds, and what question a theme answers. On the first, the requirements are concurrent, since recording, provenance, and evaluation all bind at or before the moment of action. On the second, the questions retain an order, since a party cannot reconstruct an act that has not occurred. #5 specifies the reference; this theme specifies the evaluation of an action against it; #1 specifies the record. Of the three, this is the only one specifying a decision rather than an artifact, which is where interoperability bites: two implementations can agree on a provenance format and a record format and still disagree on whether a given action conformed.

Scope / Open Questions

Three tasks. Tasks 1 and 2 are from the original theme; task 3 is the proposed extension.

Task 1, expression. How can a security policy be expressed as an intent, independent of the actors and agents involved? Features and limits, including the semantic-delegation risk raised on July 29 (Xiaoya Yang): a properly authenticated, authorized delegation can still be interpreted differently than the delegator intended. The hard case #5 raises borders this task and splits in two: whether a natural-language goal constitutes a grant of authority at all is prior and belongs to #5, since by the time an evaluator sees anything a grant has been assumed; how conformance is tested against an imprecise reference, and with what confidence, belongs here.

Task 2, coexistence. How do classical identity-bound policies and intent-based policies coexist? Do they compose at one enforcement point, or need separate ones?

Task 3, runtime verification and conformance verdicts. Requirements for evaluating an agent's actions against an intent-expressed policy set at the time of action; adjudication when multiple intents are in tension (collision, precedence, criticality); and the conformance verdict the action record (see #1) must be able to carry.

Per discussion on #1, the record should be able to carry a verdict with defined semantics rather than require one, so that deployments with no policy engine in the path remain expressible. That raises two requirements this task carries. First, a carried verdict is a claim by the engine that issued it, so its semantics must cover binding to the issuing engine's identity, freshness, and tamper evidence: a verdict is closer to a small attestation than to a field. Second, absence must be attested rather than merely permitted. If the field is optional and unattested, an operator whose engine returned block is indistinguishable from an operator with no engine in the path, which defeats the verifiability criterion #1 sets. Null semantics are therefore part of verdict semantics.

Following the structural and semantic distinction raised on #4, a verdict carries decision authority when it is reproducible against a versioned reference: the same input evaluated against the same reference version yields the same verdict. That holds for semantic evaluations as much as structural ones, and sits alongside the attribution and appraisal requirements above. Where an evaluation cannot meet that bar, the honest output is escalate or indeterminate.

Per discussion on #5, the policy set is an authored artifact rather than a given. The reference must carry provenance in both directions: the authority under which it was authored, and the version in force at the time of a given evaluation.

Per discussion on #9 and #16, the verdict vocabulary is five states, not four: permit, remediate, block, escalate to a human, and indeterminate. Indeterminate is the honest verdict where the reference is imprecise or absent, or where confidence falls below a declared threshold, and it is carried with scope: what was examined, over what period, as of when. It is distinguishable both from a verdict in the first four states and from an attested absence of evaluation. The three states settled in #9 for the record (reference established; bounded search performed and returned nothing; nothing recorded) therefore have verdict-side counterparts: a verdict in one of the first four states; indeterminate with scope; and attested absence. #16 reaches the same state as INDETERMINATE from the intervention side and #9 as operationally undecidable, which is three directions arriving at one requirement.

Per the contribution of 2 September (AVS-0.1), task 3 operates on two axes. The action axis carries the five verdict states. The evidence axis carries the appraisal checks and a closed, tiered rejection-class set, referenced by version; a rejection is a statement about the record, never a sixth verdict and never indeterminate. AR4SI's no-assertion result is an evidence-side outcome and must not be read as action-side indeterminate. The parameters that shape a verdict (the confidence threshold against which a verdict on an imprecise reference is judged, the precedence order between colliding obligations, and criticality weights) are properties of the reference, authored and versioned with the policy set and subject to #5's standing. A relying party may raise a threshold above the reference's floor; a producer never declares any of them, and AVS-0.2's C10 rejects a record that supplies its own threshold. The confidence value remains an attributed engine claim whose honesty is not decidable from the record, which is the interface to external evaluation in #18. Per the contribution of 2 September on the issuer-to-subject edge, the carried claim declares the issuing engine's relationship to the evaluated party (self, contracted, or independent), with silence non-conforming; the field composes with the reference's authorship provenance rather than restating it; its truth is not decidable from the record and its verification is a provenance question about the issuer under #5; requirements against it are written per decision class, stated in the reference, never as a blanket.

Open questions for this thread:

1. How do we test or verify compliance with a fuzzy, intent-expressed policy?
2. Can intent-based and classical models compose, or do they need separate enforcement points?
3. When intents collide, what adjudication semantics are standardizable?
4. What semantics does a carried conformance verdict need in order to be verifiable by a party with no relationship to the issuing engine, how is the absence of an evaluation attested rather than merely omitted, and how is indeterminate kept distinguishable from both a forced verdict and an attested absence? Raised on #1.
5. Under whose authority is a policy set authored, and what does a reference carrying no provenance leave a relying party able to challenge? Raised on #5; the standing question belongs there, the evaluation consequences here.
6. What does an evaluation presuppose about its reference? Well-formedness is required. Legitimacy of the grant is not: an evaluation against an illegitimately granted policy set still returns a sound verdict about conformance to that set, and what legitimacy determines is whether the verdict matters. Worth settling, since it determines whether the relation to #5 is a foundation or a named interface.
7. The evaluator is itself an attack surface. What does an adversary who targets the engine or the reference rather than the agent look like (adversarial inputs to the evaluator, a substituted or downgraded reference, a captured engine issuing attributed false verdicts), and which of those are detectable from the record versus only by external evaluation? Raised on the 2 September call and by the counter-control-plane case on #18.

A concrete grounding candidate for a minimal viable pilot: regulated financial services. Obligations under FINRA, SEC, and the EU AI Act are already intent-shaped ("no performance guarantees," "required risk disclosure present") rather than identity-shaped, and give the group real policy corpora to test expression and verification against. From deployment experience enforcing organizational and regulatory policy on AI outputs at regulated institutions, expression is the easier half; verification under collision is where systems fail.

Related Work

OASIS XACML 3.0 and NIST SP 800-162 (ABAC) as the classical policy-expression baseline; IRTF RFC 9315 (intent-based networking concepts) as prior standards art on "intent"; IETF WIMSE on workload identity; IETF RATS/EAT for the attestation linkage in task 3; ITU-T X.1285 for the identity layer this work assumes; SG17's XSTR.magAI-behavior, adjacent to task 3.

One research input: our 29 July study on whether behavioral properties survive model distillation (open weights, evaluation instrument, and methodology public: https://ctgt.ai/research/distillation-censorship-transfer). In our measurements a salient behavioral property of the teacher did not survive distillation into a different base, and a self-distilled control matched the teacher-distilled variants. Relevant here as evidence that provenance- and design-based assurance under-determines behavior, which is the case for runtime verification complementing design-time and provenance approaches and which bears on the anchor-integrity discussion in #5: the failure shape is a claimed property bound to an actual one that does not follow from it, where a check consulting only the claim returns correct. The evaluation instrument may be reusable as a starting point for testing compliance with fuzzy policies.

draft-sokolov-rats-aep-composition-06 §9; RATS AR4SI for the evidence-side result vocabulary; Risk-Adaptive Access Control (NIST CSRC glossary) as prior art for adjudication under criticality, raised on the 2 September call.

Related Themes

#4 (Access control and security policy enforcement with metamorphing agents): closest neighbor. Tasks 1–2 here overlap its access-control scope, and the metamorphing premise strengthens the case for task 3: if an agent's composition and behavior change over its lifetime, design-time assurance under-determines runtime behavior, and verification has to move to the moment of action. Candidate for coordination or merge as both mature.

#1 (Accountability and attribution after an agent has acted): explicit interface, refined in that thread. #1 specifies what a record must be able to carry and what properties any carried claim needs; this theme specifies what a conformance claim asserts, how a verifier checks it, and what an attested absence of evaluation means. Attribution establishes who acted, under whose authority, within what declared scope; the verdict establishes whether the act conformed to it. The requirements are concurrent; the questions are distinct.

#5 (Provenance of authority): produces the reference this theme evaluates against, and specifies rather than verifies. Two binds. The named, versioned policy set in task 3 is itself an authored artifact whose standing #5 covers. And an evaluation presupposes a well-formed reference but not a legitimately granted one, which locates the relation at a named interface rather than a foundation. On the anchor-integrity case raised there: conformance checking of an authority structure is blind to a corrupted root, since it compares the structure to itself. Behavioral evaluation does not consult the credential chain, which makes it the only layer whose observations are generated independently of the root. Not a detector, but a second independent source of the kind #1 describes as comparable against the world rather than against the authored reference.

#3 (Global trust and accountability): the governance layer, per its proposer's framing. The dependency runs through #1: conformance verdicts feed the record; the record makes liability frameworks operable. The regulated-FS grounding here is a concrete jurisdictional instance #3's policy guidance could draw on.

7 (Verifier-side requirements and failure semantics): input to task 3. The appraisal side of a verdict, individually testable checks with normative failure semantics and frozen must-reject vectors, delivered as AVS-0.1 on 2 September; task 3 references it by version and owes the collision and multi-hop cases in return. Null-case vectors (an omitted verdict with an engine in the path) are included, per the attested-absence requirement. Updated to AVS-0.2 (C9, C10, MR-07 revised; MR-09, C11 added).

9 (Joint: #5, #1, #6, authority never crisply authored): the joint sub-thread for the fuzzy-reference case. Task 1 carries the evaluation half: conformance against an imprecise reference as a scoped, authored measurement with stated confidence; below a declared threshold the verdict is indeterminate. The three record states settled there (reference established; bounded search returned nothing; nothing recorded) have verdict-side counterparts in task 3.

16 (Operational human oversight): consumer of task 3's escalate and indeterminate verdicts. The handoff record from this theme to #16 is the verdict, the named and versioned policy set evaluated, the intents in collision and their criticality, and for indeterminate, the scope examined. #16's non-curative approval rule and its conformance-does-not-confer-authority test are consistent with the presupposition point above.

18 (Trustworthiness of multi-objective agentic AI, raised on behalf of SG17 work item XSTR.magAI-behavior): its declaration subset is reference-side, with #5; its external-evaluation subset is task 3 generalized, conformance of observed behavior to a declared reference as a scoped, authored measurement. The evaluation instrument in Related Work is an existence proof that external measurement against a declared reference is tractable with independent judges.

19 (Lifecycle-wide privacy): a transversal profile applied to this theme's artifacts rather than a parallel theme. The requirement it lists for #6, verifying conformance without disclosing the principal's full intent or policy, is already a task 3 requirement from the #4 exchange.

From the July 29 candidate list: theme 1 (design-based identity) shares the premise that identity does not predict behavior and anchors assurance at design time; this theme covers the runtime side. Theme 3 (remote attestation): the verdict in task 3 is a candidate for the behavioral portion of an agent EAT profile. Theme 6 (trust stack): this work sits at the authorization layer and adds a conformance function adjacent to it.

20 (identity/binding layer, placed from title, provisional).

21 (reads task 3's outputs at population scale; proposes no change here; sits between record and governance).

22 (attestation; interface as stated there: the policy set and engine as things to attest, the verdict as the behavioral claim the attestation carries, AR4SI evidence-side vs indeterminate action-side)

23 (Authorization and privilege lifecycle, SG17 work item X.aplm-aia): governs what privileges an agent holds over its lifecycle, and lists intent-based authorization among its dimensions; this theme concerns whether a given output met a given obligation.

26 (Cryptographic runtime enforcement boundary): the enforcement point that acts on task 3's verdict. Binding a decision to a hashed policy version is the policy-set provenance requirement here; a fail-closed gate has to state what it does with escalate and indeterminate.

Discussion

Open. Scope boundaries with #4, #1, and #5 are flagged above and worth settling before the 30 September call. Revisions to this body following discussion on those threads are summarized in the comments.