TA-Intent: Intent
Declaration Protocol
RFC Identifier: TA-Intent Version:
0.1 Status: Preliminary / Experimental
Date: 2026-03-19 Authors: Robin
Martherus, Claude Related RFCs: TA-Normative,
TA-TrustProof, TA-Attestation, TA-Provenance Normative
References: KTP-Core, KTP-Enforce, KTP-Identity,
KTP-Federation, KTP-Provenance Repository: docs/rfcs/
Related Research:
docs/research/2026-03-11-agent-governance-layers.md,
docs/research/2026-03-16-scenario-walkthroughs.md Design
Spec:
docs/superpowers/specs/2026-03-19-ta-rfc-set-design.md
Table of Contents
- Abstract
- Status of This
Document - Terminology
- Introduction and
Motivation - Architecture Overview
- Data Model
- Protocol Flows
- Integration Points
- Worked Examples
- Security
Considerations - Privacy Considerations
- Open Questions
- References
1. Abstract
This document defines the Intent Declaration Protocol (TA-Intent),
the first of five Tamed Autonomy governance primitives. TA-Intent
specifies the format, lifecycle, and enforcement semantics for
intent declarations: structured, machine-readable
purpose statements that an agent submits before acting, and that serve
as enforceable behavioral contracts for the duration of the agent’s
session or task.
An intent declaration is not a request for permission. It is a
binding commitment by the agent about what it will do, on whose behalf,
against which resources, within what constraints, and for how long. The
governance system does not primarily ask “is this agent allowed to act?”
— that question belongs to access control. It asks “does this agent’s
declared purpose constitute a legitimate and governable contract, and do
its subsequent actions stay within that contract?” These are
categorically different governance questions that require categorically
different primitives.
TA-Intent defines: the Intent Declaration Object (the wire format),
the scope contract semantics, the contract lifecycle state machine, four
protocol flows (declaration and binding, per-action scope enforcement,
scope amendment, and composite intent binding for multi-agent swarms),
and integration points with the other four Tamed Autonomy
primitives.
TA-Intent is the foundational protocol of the Tamed Autonomy
framework. The other four RFCs — TA-Normative, TA-TrustProof,
TA-Attestation, and TA-Provenance — each depend on or extend the
primitives defined here.
2. Status of This Document
This document is a Preliminary/Experimental RFC
(version 0.1). It represents current design thinking for the Tamed
Autonomy framework and has passed internal design review. It is not a
finalized specification and MUST NOT be treated as a production
implementation standard.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119.
Feedback and challenges to the design are actively solicited. Open
questions are documented in Section 12. The design is expected to evolve
significantly as implementation experience is gained, particularly in
the areas of scope language formalism (Section 12.1), amendment
accumulation handling (Section 12.2), and multi-principal intent
(Section 12.4).
This RFC is part of a set of five preliminary specifications:
| RFC | Primitive | Type |
|---|---|---|
| TA-Intent (this document) | Intent Declaration Protocol | TA-original |
| TA-Normative | Normative Constraint Protocol | TA-original |
| TA-TrustProof | Trust Proof Extension | KTP extension |
| TA-Attestation | Behavioral Attestation Extension | KTP extension |
| TA-Provenance | Provenance Extension | KTP extension |
3. Terminology
This section defines all terms used in this document. Terms from KTP
specifications (KTP-Core, KTP-Enforce, KTP-Identity) are reproduced here
with attribution for reader convenience; the KTP specifications are
normative.
Action Risk Score (A): A numeric value in the range
[0, 100] assigned to a specific action type against a specific resource
class, representing the potential harm of that action if misused.
Defined per KTP-Core. Actions with A scores exceeding the agent’s
current E_trust are blocked by the Silent Veto. Organizations calibrate
A scores against canonical risk classes (Heartbeat=5, Read Public=10,
Read Private=30, Write Append=40, Write Modify=50, Execute Safe=60,
Delete=75, Admin=90, Destructive=95).
Amendment: A formal request by an agent to extend
its active scope contract to include resources, action types, or
constraints not present in the original declaration. Amendments are
subject to the amendment_policy defined in the Intent
Declaration Object and, if approved, cause a state transition from
bound to amended. See Section 6.3 (Contract
Lifecycle) and Protocol Flow 3.
Behavioral Contract: The enforceable constraint
relationship created when an intent declaration reaches the
bound state. The governance layer treats the bound scope as
a contract: actions within the declared scope are evaluated by the
enforcement pipeline; actions outside the declared scope are blocked by
a contract violation before the enforcement pipeline runs. The agent’s
subsequent behavior is monitored against this contract through
TA-Attestation.
Composite Intent: The aggregate purpose
reconstructed by the analysis layer from the individual intent
declarations of two or more agents operating in a swarm session.
Composite intent may differ materially from any individual agent’s
declared intent. Composite intent is evaluated by TA-Normative as a
unit. See Section 6.4 and Protocol Flow 4.
Contract Lifecycle: The state machine governing the
valid states and transitions of an intent declaration from initial
submission through terminal states. Valid states are:
declared, evaluating, bound,
amended, composite_suspended,
violated, expired, terminated.
See Section 6.3.
Contract Status: The current state of the contract
lifecycle for an active intent declaration. Carried in the
contract_lifecycle.status field of the Intent Declaration
Object and reflected in the
ta_extension.intent_compliance.contract_status field of the
Trust Proof (TA-TrustProof).
Data Classification Ceiling: A constraint within a
scope entry that sets the maximum data sensitivity level the agent is
permitted to access for that resource. Classifications follow the
organization’s DLP/classification taxonomy (e.g., public, internal,
confidential, trade_secret). An agent MUST NOT access data above its
declared ceiling for a scope entry, regardless of other
authorization.
Delegation Chain: An ordered list of agent and human
principals through whom authority has been delegated from the
originating human principal to the current agent. An empty delegation
chain indicates the agent is acting directly on behalf of the human
named in on_behalf_of. Non-empty chains connect to the
purpose chain defined in TA-Provenance.
E_trust (Trust Score): The current computed trust
score of an agent, defined by KTP-Core as
E_trust = E_base × (1 - R). E_trust determines the agent’s
Trust Tier and constrains which action risk scores the agent can execute
(Silent Veto: if A > E_trust, action is denied). Not to be confused
with authorization or intent compliance — an agent can have high E_trust
and still be blocked by a scope contract violation.
Intent Declaration: A structured, machine-readable
document submitted by an agent before beginning a task, stating the
agent’s purpose, the resources it intends to access, the action types it
intends to perform, the constraints it accepts, the human principal on
whose behalf it acts, and the intended duration. An intent declaration
becomes a behavioral contract when it reaches the bound
state.
Intent Declaration Object: The JSON wire format for
an intent declaration, as defined in Section 6.1. Contains all mandatory
and optional fields of the declaration, including the scope,
on_behalf_of, duration, amendment policy, composite context, and
contract lifecycle state.
Intent ID: A globally unique, dereferenceable URI
identifying a specific intent declaration instance. Format:
intent://{organization-domain}/session/{ISO8601-timestamp}/{random-suffix}.
Intent IDs are referenced by TA-TrustProof (active_intent_id),
TA-Attestation (intent_id per action), and TA-Provenance (intent_id at
each delegation depth).
On Behalf Of: The field in the Intent Declaration
Object identifying the human principal (or organizational role) whose
authority the agent is acting under. Agents MUST NOT claim to act on
behalf of principals from whom no delegation has been received. The
on_behalf_of.delegation_chain provides the verifiable link between the
declared principal and the acting agent.
Parent Intent ID: An optional field in the Intent
Declaration Object linking a child agent’s declaration to the intent
declaration of its spawning parent agent. When present, the governance
layer performs scope containment verification: the child’s declared
scope MUST be a subset of the parent’s approved scope at the time of the
child’s declaration. See TA-Provenance for the full purpose chain
model.
Purpose: The human-readable and taxonomy-classified
statement of what the agent intends to accomplish. Purpose is the
primary input to TA-Normative evaluation. A purpose consists of a
natural language description and a structured taxonomy classification
(domain, action_class, sensitivity). Purpose is not directly enforced —
scope entries are the enforceable expression of purpose.
Scope Contract: The binding set of scope entries
that an agent has committed to operate within, as approved and
potentially modified by the normative evaluation. The scope contract is
the primary enforcement artifact of TA-Intent. See Section 6.2.
Scope Distance: A float value in [0.0, 1.0] produced
by the scope evaluator for each agent action, representing the semantic
distance between the requested action and the nearest matching scope
entry. 0.0 indicates exact match; values approaching 1.0 indicate no
relationship to any declared scope entry. Scope distance feeds the KTP
Soul Dimension goal stability sensor through TA-Attestation.
Scope Entry: A single element of the scope array in
an Intent Declaration Object. A scope entry specifies one resource (by
URI), one action type (READ, WRITE, EXECUTE, DELETE, ADMIN, SHARE), and
zero or more constraints (time range, path pattern, data classification
ceiling, record level, operation type). The full scope is the union of
all scope entries.
Scope Match: The categorical result of scope
evaluation for an agent action. Values: within (action
fully within declared scope), boundary (action at the edge
of declared scope), outside (action outside declared scope
→ contract violation). See TA-Attestation for scope match semantics and
enforcement consequences.
Silent Veto: KTP-Core mechanism. When A >
E_trust, the action is denied without error notification to the agent.
The enforcement pipeline returns a denial response, but the reason given
does not indicate the physics check failure specifically. Intent to
mislead or ambiguous agent behavior cannot exploit knowledge of the
exact threshold at which they were blocked.
Soul Constraint: A binary veto (S=1) generated by
TA-Normative when a normative constraint fires. Soul constraints are
applied at step 2 of the KTP enforcement pipeline, before tier gate and
physics checks. An action subject to an active Soul Constraint is denied
regardless of E_trust. Soul constraints generated by TA-Normative are
distinct from KTP’s native Soul Dimension (which reflects behavioral
signals); both produce S=1 vetoes. See TA-Normative for Soul Constraint
definitions.
Swarm Session: A runtime evaluation context created
by the analysis layer when two or more agents are detected as operating
in coordination. Agents in a swarm session have their individual intent
declarations evaluated not only individually but also as constituents of
a composite intent. Swarm session binding criteria are defined in
TA-Attestation Section 6 (composite behavior detection). Swarm session
membership is determined by the analysis layer, not self-declared by
agents.
Trust Tier: The categorical trust level
corresponding to ranges of E_trust, defined by KTP-Core. Tiers determine
which action categories an agent may attempt regardless of A score (tier
gate, enforcement pipeline step 3). Tiers in ascending order:
Hibernation (E_trust < 50), Observer (50 ≤ E_trust < 60), Analyst
(60 ≤ E_trust < 75), Operator (75 ≤ E_trust < 90), God Mode
(E_trust ≥ 90).
4. Introduction and Motivation
4.1 The Governance Gap
Current agent integration protocols — MCP, OAuth 2.0, RBAC,
SPIFFE/workload identity — govern who can act and
what they are authorized to access. They do not govern
why an agent is acting or whether it
should. As AI agents acquire greater autonomy, capability, and
access breadth, this governance gap widens into a systemic risk.
The core failure mode is not that authorized agents maliciously
override access controls. It is that authorized agents, operating within
their credential scope, take actions that diverge from the purpose for
which they were deployed, and no existing control layer detects or
prevents the divergence. Consider:
- An agent authorized to access CRM data for quarterly reporting also
accesses CRM data to compile a competitive intelligence dossier. Both
uses are within the same OAuth scope. The difference is purpose, not
authorization. - An agent authorized to read code repositories for a bug fix is
manipulated by a compromised tool into reading secrets files. The
secrets read is within the agent’s access scope. The difference between
the legitimate and illegitimate read is intent, not credential. - Three agents, each with narrow and individually legitimate purposes,
coordinate to form a data exfiltration pipeline. Each individual intent
passes normative review. The aggregate does not. No per-agent control
surface reveals the composite pattern.
These failures share a structure: access control answers
“can?” but not “why?” or “should?” Intent declarations are the
missing primitive that makes “why?” answerable and enforceable at the
protocol level.
4.2 The Governance Layer Model
Tamed Autonomy frames agent governance as a three-question
hierarchy:
| Question | Layer | Current State |
|---|---|---|
| Can it? | Access Control (MCP, OAuth, RBAC) | Exists but has structural gaps for agents |
| Why is it? | Intent Declaration and Verification (TA-Intent) | Largely absent from production deployments |
| Should it? | Normative Governance (TA-Normative) | Not addressed in current production systems |
TA-Intent addresses the middle question. It is the protocol layer
that introduces purpose into the governance stack — not by replacing
access control, but by adding a semantic binding layer above it. An
agent that passes access control and presents a valid intent declaration
still must have that intent evaluated by TA-Normative (the “should”
layer) before its scope becomes an enforceable contract.
The stack from the foundational governance layers research
(docs/research/2026-03-11-agent-governance-layers.md):
+------------------------------------------------+
| "Should" — Normative / Ethical Governance | TA-Normative
| (moral reasoning, consequence modeling, |
| human as ultimate arbiter of morals) |
+------------------------------------------------+
| Trust Fabric | KTP-Core + TA-TrustProof
| (computed, earned, scoped, revocable) |
+------------------------------------------------+
| Intent Declaration & Verification | TA-Intent ← this RFC
| (what does the agent say it will do? |
| does declared intent match observed action?) |
+------------------------------------------------+
| Identity + Behavior (evaluated together) | KTP-Identity + TA-Attestation
| (who claims to be acting, | + TA-Provenance
| what is actually happening) |
+------------------------------------------------+
| Infrastructure (APIs, services, compute) | MCP, OAuth, RBAC
+------------------------------------------------+4.3 Why Existing
Approaches Are Insufficient
OAuth 2.0 and RBAC
OAuth 2.0 scopes are static and pre-defined. They describe what an
agent is permitted to access, not what it intends to do or why. RBAC
roles are stable and context-independent. Neither mechanism:
- Distinguishes between two agents with identical credentials acting
for fundamentally different purposes - Provides a semantic description of the task that can be checked
against organizational norms before the task begins - Creates a binding behavioral contract that each subsequent action is
checked against - Detects when the agent’s actions, while individually authorized,
collectively reveal a purpose different from the one declared
MCP Tool Access
MCP provides structured tool invocation for agents but does not
govern purpose. An agent with MCP access to a CRM system has the same
MCP tool access whether its purpose is quarterly reporting or
competitive intelligence compilation. Furthermore, MCP tool descriptions
can be compromised to inject instructions into the agent’s context,
causing the agent to use its authorized MCP access for purposes outside
its intended task — the Confused Deputy attack pattern documented by
Invariant Labs and classified by OWASP as “Excessive Agency.”
DLP and UEBA
Data Loss Prevention systems detect known-bad content patterns
(credentials, PII, classified markers) in data flows. User and Entity
Behavior Analytics detect statistical anomalies in access patterns. Both
are valuable compensating controls. Neither evaluates whether a specific
access pattern is consistent with a declared purpose. An agent that
reads aggregate revenue data instead of individual revenue records may
not trip a DLP rule even though it is accessing data inconsistent with
its declared scope. An agent synthesizing content from multiple
authorized sources into a knowledge transfer document may not look
anomalous to UEBA even when its actual purpose is intellectual property
extraction.
The Competitive Landscape
No current production system provides intent as a governance
primitive. The competitive analysis
(docs/research/2026-03-12-competitive-analysis.md) documents that the
market broadly addresses “can” but not “why” or “should.” The closest
emerging work is Mastercard/Google’s Verifiable Intent Framework (March
2026), which verifies that payment intents match transaction patterns.
TA-Intent generalizes the same principle to all agent actions in any
governed environment, embedding it into a full protocol with lifecycle
management, scope enforcement, amendment handling, and multi-agent
composite evaluation.
4.4 Intent as Contract
The core design principle of TA-Intent is that the intent declaration
operates as a contract, not a confession. The
governance system does not need to trust that the agent’s declared
intent is sincere. It uses the declaration as a binding constraint to
enforce against:
- If the agent declares narrow scope and operates within it, the
contract is honored. The agent is constrained to what it declared. - If the agent declares narrow scope and attempts to act outside it,
the contract catches the violation at the per-action scope evaluation —
before the action executes. - If the agent declares broad scope, TA-Normative evaluates whether
the aggregate purpose is appropriate and, if not, narrows the scope or
denies the declaration before any action begins.
This is analogous to legal contracts: it does not matter what an
agent secretly intends. What matters is what it declared, whether the
declaration passed normative review, and whether its subsequent actions
comply. The agent is governed either way.
4.5 MCP Bypass and
the Need for a Purpose Layer
A specific motivation for TA-Intent is the structural bypass problem
with MCP governance. As documented in the WebMCP bypass analysis
(docs/research/2026-03-19-webmcp-bypass-analysis.md), MCP servers often
share credentials with web and direct API access paths. A sufficiently
capable agent that obtains credentials can reach the same services
through alternate paths, bypassing MCP-specific policy enforcement.
This makes MCP primarily a convenience and orchestration layer rather
than a reliable security boundary. Within the governed enclave (where
all access paths enforce TA governance), a purpose layer resists bypass
through alternate access paths, because it governs agent intent before
any path is selected. An agent that circumvents MCP to access a service
directly still carries its intent declaration — and any action taken
against a resource outside that declaration is a contract violation
detectable through TA-Attestation’s scope evaluation. Outside the
governed enclave, agents can bypass purpose-layer enforcement by
accessing services through ungoverned paths. Extension to ungoverned
environments depends on the governed enclave growing through voluntary
adoption (see docs/research/2026-03-11-agent-governance-layers.md, “How
Paradigm Shifts Actually Happen”).
5. Architecture Overview
5.1 Position in the Tamed
Autonomy Stack
TA-Intent sits at the third layer of the five-layer Tamed Autonomy
architecture, above identity and behavioral infrastructure and below the
normative governance layer. It connects the behavioral record (what the
agent does) to the purpose evaluation (whether it should).
┌─────────────────────────────┐
│ TA-Normative │
│ (normative evaluation, │
│ soul constraints, │
│ risk reclassification) │
└────────────┬────────────────┘
│ evaluates intent;
│ returns approval +
│ constraints
┌────────────▼────────────────┐
│ TA-Intent │
│ (intent declaration, │◄── this RFC
│ scope contract, │
│ per-action enforcement, │
│ amendment, composite) │
└────────────┬────────────────┘
┌──────────────────┼──────────────────┐
│ │ │
┌──────────▼─────┐ ┌────────▼────────┐ ┌──────▼──────────┐
│ TA-TrustProof │ │ TA-Attestation │ │ TA-Provenance │
│ (intent state │ │ (per-action │ │ (purpose chain,│
│ in trust │ │ scope eval, │ │ delegation │
│ proof token) │ │ compliance │ │ verification) │
│ │ │ record) │ │ │
└────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
└──────────────────▼───────────────────┘
┌───────────────────────────────┐
│ KTP-Core / KTP-Enforce │
│ (trust physics, enforcement │
│ pipeline, trajectory chains,│
│ sponsorship bonds) │
└───────────────────────────────┘5.2 The Enforcement Pipeline
Every agent action passes through the KTP enforcement pipeline
(defined in KTP-Enforce). TA-Intent integrates at two points in this
pipeline:
Step 1 Signature validation Is the Trust Proof cryptographically valid
and unexpired?
TA: Additionally check contract_status not in
{violated, expired, terminated, composite_suspended} AND
clearance_level != restricted (from TA-TrustProof)
Step 2 Soul veto check Is S = 1 for this action?
Sources: KTP Soul Dimension (behavioral signals)
TA-Normative soul constraints (policy signals)
If S = 1 from either source → action denied regardless
of trust score
Step 3 Tier gate Is this action category permitted at the
agent's current Trust Tier?
Step 4 Physics check Is A ≤ E_trust?
A may have been reclassified by TA-Normative
If A > E_trust → Silent VetoTA-Intent inserts scope contract enforcement between Steps 2
and 3 of this pipeline — after signature validation and soul
veto check, before the tier gate and physics check. If the requested
action is outside the declared scope (scope_match: outside), the action
is denied as a contract violation at this point. The rationale for this
position: signature validation (Step 1) MUST occur first, because an
invalid or forged trust proof should be rejected before any
computational resources are spent on scope evaluation. Soul veto (Step
2) fires before scope because normative constraints (S=1) represent
categorical ethical blocks that apply regardless of declared scope. Only
after both checks pass does scope enforcement run. This ordering is
architecturally significant: the scope contract catches what trust
physics cannot. An agent with high E_trust attempting an out-of-scope
action at a modest A score would pass the tier gate and physics check —
but is blocked by the contract violation at the scope enforcement
step.
The complementary enforcement pattern: – Trust
physics provides the hard floor: A ≤ E_trust at all times,
regardless of declared purpose – Scope contract
provides the semantic ceiling: actions must be within declared and
approved scope – Normative layer provides the
context-dependent veto: even in-scope, in-physics actions can be denied
based on organizational context
5.3 Enforcement Points
The governance primitives defined in this RFC and its siblings are
deliberately agnostic about where enforcement occurs. Agents access
resources through many paths — service APIs, MCP servers, browsers,
shell commands, file systems, message platforms — and not all of these
paths involve network traffic. The governance architecture MUST NOT
assume HTTP service boundaries as the only enforcement point.
Implementations SHOULD deploy enforcement at whatever points exist in
the agent’s access paths:
- Service API endpoints and MCP gateways — require
trust proofs and intent declarations as conditions of API access - Identity providers and SSO flows — enforce
governance at session establishment so that services behind SSO inherit
governance state through the authenticated session - Network proxies and CASBs — inspect and annotate
agent traffic at the network layer - Operating system and endpoint management — enforce
governance for locally-running agents through sandboxing and process
isolation - Agent runtimes and containers — control which
binaries, filesystems, and network destinations agents can reach - The browser — enforce governance for browser-based
agent actions at the browser, session, or web application level
A service is governed only if every access path to it includes at
least one enforcement point. Not every enforcement point must implement
the full governance stack — a lightweight point MAY only validate a
trust proof, while a full point MAY evaluate intent, run normative
constraints, and record behavioral attestations.
This RFC defines the intent declaration primitive and its enforcement
semantics. Where those semantics are enforced is an implementation
decision driven by the agent’s access paths and the deployment
environment.
5.4 Relationship to KTP
TA-Intent is designed to work with the Kinetic Trust Protocol (KTP)
as the trust physics substrate. All references to trust computation
(E_trust, E_base, R), Trust Tiers, enforcement pipeline steps, Soul
Dimension, Trajectory Chains, Sponsorship Bonds, and Silent Veto are as
defined in KTP-Core and KTP-Enforce.
TA-Intent does not modify the KTP trust computation or enforcement
pipeline. It adds a new governance layer above KTP that feeds into the
enforcement pipeline through two well-defined integration points: (1)
soul constraints generated by TA-Normative that produce S=1 vetoes, and
(2) action risk reclassifications that modify A scores before the
physics check. Both mechanisms are defined in TA-Normative; TA-Intent is
the declaration primitive that triggers the normative evaluation that
produces those outputs.
6. Data Model
6.1 Intent Declaration Object
The Intent Declaration Object is the canonical wire format for an
intent declaration. It MUST be submitted in full at declaration time and
MUST be signed by the declaring agent. The governance layer MUST
validate the signature before beginning evaluation.
{
"intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/a1b2c3",
"version": "0.1",
"purpose": {
"natural_language": "Generate Q4 revenue summary by region for leadership meeting",
"taxonomy": {
"domain": "business_intelligence",
"action_class": "data_retrieval_and_synthesis",
"sensitivity": "confidential"
}
},
"scope": [
{
"resource": "crm://salesforce/revenue",
"action_type": "READ",
"constraints": {
"time_range": "Q4-2025",
"aggregation": "by-region",
"data_classification_ceiling": "confidential",
"record_level": "aggregate_only"
}
},
{
"resource": "finance://sap/revenue",
"action_type": "READ",
"constraints": {
"time_range": "Q4-2025",
"data_classification_ceiling": "confidential"
}
},
{
"resource": "storage://onedrive/shared/templates",
"action_type": "READ",
"constraints": {
"path_pattern": "presentation-templates/*"
}
},
{
"resource": "storage://onedrive/sarah.chen/workspace",
"action_type": "WRITE",
"constraints": {
"operation": "create_new",
"data_classification_ceiling": "confidential"
}
}
],
"on_behalf_of": {
"principal": "user://company.com/sarah.chen",
"principal_type": "human",
"delegation_chain": []
},
"duration": {
"type": "session",
"max_ttl": "PT4H",
"renewable": false
},
"parent_intent_id": null,
"amendment_policy": {
"auto_approve_within": "same_resource_different_constraint",
"require_human_approval": "new_resource_or_action_type",
"deny": "classification_ceiling_increase"
},
"composite_context": null,
"contract_lifecycle": {
"status": "declared",
"valid_states": [
"declared",
"evaluating",
"bound",
"amended",
"composite_suspended",
"violated",
"expired",
"terminated"
],
"transitions": {
"declared": ["evaluating", "terminated"],
"evaluating": ["bound", "terminated"],
"bound": ["amended", "composite_suspended", "violated", "expired", "terminated"],
"amended": ["bound", "composite_suspended", "violated", "expired", "terminated"],
"composite_suspended": ["bound", "violated", "terminated"],
"violated": ["terminated"],
"expired": [],
"terminated": []
}
}
}6.1.1 Field Definitions
intent_id (REQUIRED) A globally unique URI
identifying this declaration instance. Format:
intent://{org-domain}/session/{ISO8601-timestamp}/{random-suffix}.
The random suffix SHOULD be at least 6 cryptographically random
alphanumeric characters. The intent_id MUST be unique across the
organization’s governance namespace. MUST remain stable across
amendments (the amended declaration retains the original intent_id).
version (REQUIRED) The TA-Intent specification
version this declaration conforms to. Current value:
"0.1".
purpose (REQUIRED) The agent’s stated purpose.
Contains two sub-fields: – natural_language (REQUIRED): A
human-readable description of the task. MUST be specific enough that a
human reviewer could evaluate its legitimacy. Governance layer MAY
reject declarations with insufficient specificity and initiate
AI-mediated intent negotiation to clarify. – taxonomy
(REQUIRED): Structured classification enabling automated normative
evaluation. – domain: The organizational domain of the task
(e.g., business_intelligence,
software_development, clinical_care,
financial_reporting). – action_class: The type
of operation being performed (e.g.,
data_retrieval_and_synthesis,
code_modification, document_creation,
external_communication). – sensitivity: The
highest data sensitivity level the declared scope touches. Values MUST
align with the organization’s DLP classification taxonomy.
scope (REQUIRED, array, minimum 1 entry) The set of
resources, action types, and constraints the agent commits to operate
within. Each entry is a Scope Entry (see Section 6.2). The scope array
MUST cover all resources and action types the agent anticipates needing.
Attempts to act against resources or action types not present in the
scope array MUST be treated as contract violations. Governance MAY
require the agent to declare its full anticipated scope and MAY reject
declarations that appear under-scoped relative to the stated
purpose.
on_behalf_of (REQUIRED) The human principal or
organizational role on whose authority the agent is acting. Fields: –
principal (REQUIRED): URI identifying the human or role.
Format: user://{org-domain}/{username} for humans,
role://{org-domain}/{role-name} for organizational roles. –
principal_type (REQUIRED): "human",
"organizational_role", or "agent". Use
"human" for named individual users,
"organizational_role" for team or functional roles (e.g.,
role://company.com/sales-team), and "agent"
when an agent system (rather than a human) is the delegating principal.
These values align with the principal_type enum in TA-Provenance. –
delegation_chain (REQUIRED): Ordered array of intermediate
principals between the depth-0 human and the declaring agent. An empty
array means the agent is directly sponsored by the named principal. Each
entry in the chain MUST reference a valid TA-Provenance purpose chain
depth entry. See TA-Provenance for purpose chain semantics.
duration (REQUIRED) The intended duration of the
scope contract. Fields: – type (REQUIRED):
"session" (terminates when the user session ends),
"task" (terminates when the specific task completes),
"fixed" (terminates after max_ttl), or
"ongoing" (subject to renewal). – max_ttl
(OPTIONAL for session/task, REQUIRED for fixed/ongoing): ISO 8601
duration string (e.g., "PT4H" for 4 hours,
"P2W" for 2 weeks). Governance layer MUST enforce this
ceiling. A duration type of "ongoing" MUST specify
renewable: true and a max_ttl for the renewal
period. – renewable (REQUIRED): Boolean. If
false, the contract expires at the end of its duration
without possibility of renewal. If true, the agent MAY
request renewal subject to re-evaluation.
parent_intent_id (OPTIONAL) The
intent_id of the parent agent’s active intent declaration,
when this declaration is submitted by a child agent acting under
delegated authority. When present, the governance layer MUST perform
scope containment verification: the child’s declared scope MUST be a
subset of the parent’s approved scope. If the parent’s intent has been
revoked or violated since the child was spawned, this check MUST fail.
See Section 7.4 (Protocol Flow 1, composite intent) and TA-Provenance
for the full purpose chain model.
amendment_policy (REQUIRED) Declares the amendment
policy for this scope contract. Three mutually exclusive conditions: –
auto_approve_within: Amendment requests matching this
condition are auto-approved without normative re-evaluation or human
escalation. RECOMMENDED value:
"same_resource_different_constraint" (e.g., changing a time
range from Q4 to Q4+Q3 for a resource already in scope). –
require_human_approval: Amendment requests matching this
condition require explicit human approval before the scope is extended.
RECOMMENDED to apply to "new_resource_or_action_type". –
deny: Amendment requests matching this condition are denied
without escalation. MUST include
"classification_ceiling_increase" — agents MUST NOT be
permitted to unilaterally request elevation of their data classification
ceiling.
composite_context (OPTIONAL, default null) When
non-null, indicates this declaration is participating in a known
composite workflow. Fields: – swarm_session_id: URI
identifying the swarm session this agent is a member of. –
composite_role: The role this agent plays in the composite
workflow (e.g., "data_retrieval", "synthesis",
"output"). – sibling_intent_ids: Array of
intent_id values for other agents in the same declared
composite workflow.
When null, the agent declares no knowledge of coordinating with other
agents. The analysis layer may still detect and bind this declaration
into a swarm session based on behavioral signals, regardless of this
field.
contract_lifecycle (REQUIRED) The contract lifecycle
state machine. The status field MUST be set to
"declared" at submission time. The governance layer manages
all subsequent transitions. The valid_states and
transitions fields are informational (reflecting the
canonical state machine) and MUST NOT be modified by the declaring
agent. See Section 6.3.
6.2 Scope Entry
A Scope Entry defines a single permitted interaction: one resource,
one action type, and zero or more constraints. The union of all scope
entries constitutes the agent’s scope contract.
{
"resource": "crm://salesforce/revenue",
"action_type": "READ",
"constraints": {
"time_range": "Q4-2025",
"aggregation": "by-region",
"data_classification_ceiling": "confidential",
"record_level": "aggregate_only"
}
}resource (REQUIRED) A URI identifying the resource
or resource class. The URI scheme MUST correspond to a registered
resource type in the organization’s resource registry (e.g.,
crm://, finance://, storage://,
clinical://, code://). Wildcard patterns
(e.g., storage://onedrive/shared/*) MAY be used where
appropriate; governance layer MAY require specificity for
high-sensitivity resources.
action_type (REQUIRED) One of the canonical action
types: READ, WRITE, EXECUTE,
DELETE, ADMIN, SHARE.
Organizations MAY define sub-types (e.g., WRITE:create_new,
WRITE:modify_existing) that map to finer-grained action
risk scores.
constraints (OPTIONAL, object) Key-value pairs that
further restrict the permitted action. Recognized constraint keys: –
time_range: Restricts access to data from a specific time
period (e.g., "Q4-2025", "2026-01",
"last_30_days"). – path_pattern: Restricts
access to resources matching a glob pattern within the declared resource
path (e.g., "presentation-templates/*"). –
data_classification_ceiling: The maximum data
classification the agent may access for this resource. Values:
"public", "internal",
"confidential", "trade_secret". Governance
layer MUST enforce this ceiling; accessing data above the declared
ceiling is a contract violation. – record_level: The
granularity of data access permitted. Values:
"aggregate_only" (no individual records),
"individual_records" (full record access),
"anonymized" (PII-removed only). – operation:
For WRITE actions, the permitted operation type:
"create_new" (no modification of existing data),
"modify_existing", "append_only". –
destination_domain: For SHARE or external communication
actions, restricts the destination (e.g., "internal",
"partner:{partner-id}",
"external:auditors").
Organizations MAY define additional constraint keys. Constraint keys
not recognized by the governance layer MUST be treated as opaque and
logged, and SHOULD trigger a warning to the agent requiring
clarification.
6.3 Contract Lifecycle State
Machine
The contract lifecycle defines the valid states of an intent
declaration from initial submission through terminal states. All
transitions are managed by the governance layer. Agents MUST NOT
self-transition their contract state.
States and valid transitions:
declared ──────────────────────────────────────────── terminated
│ │
▼ │
evaluating ──────────────────────────────────────── terminated
│ │
▼ │
bound ─────────────────────────────────────────┬──── terminated
│ │ │
├─── [amendment request] ──► amended ───────┤ │
│ │ │ │
│ ├──── violated ──► terminated
│ │
├───────────────────── violated ──────────────► terminated
│
├──── [composite denial] ──► composite_suspended
│ │
│ ┌─────────────┼─────────────────┐
│ ▼ ▼ ▼
│ bound violated ──► terminated
│ (false positive) (confirmed
│ malicious) terminated
│ (admin decision)
│
└───────────────────── expired ──────────────► (terminal)State definitions:
declared The agent has submitted the Intent Declaration
Object. The governance layer has received it and assigned the intent_id.
No evaluation has begun. Actions are not permitted while in the
declared state. Duration: typically milliseconds to
seconds. Transitions to evaluating (on commencement of
normative evaluation) or terminated (on format validation
failure or immediate denial).
evaluating TA-Normative evaluation is in progress. The
normative engine is fetching context, evaluating constraints, and
computing the approval result. Actions are not permitted while in the
evaluating state. Duration: typically seconds; may take
longer if human escalation is required. Transitions to
bound (on approval or conditional approval) or
terminated (on denial).
bound The normative evaluation has returned
approved or conditional, and the scope
contract is active. The agent MAY now attempt actions. Each action is
checked against the scope contract. This is the primary operational
state. Transitions to amended (on approved scope
amendment), violated (on scope violation),
expired (on max_ttl reached or session end), or
terminated (on explicit termination).
amended An approved scope amendment has extended the
scope contract beyond the original declaration. The amended scope is now
the active behavioral contract. Transitions identically to
bound.
composite_suspended The agent’s individual contract has
been suspended as a participant in a composite intent that was denied by
the normative engine (Protocol Flow 4). The suspension blocks all
further actions for this agent, but does NOT mark the individual
contract as violated — the agent may have been operating
fully within its own declared scope when the composite denial occurred.
The composite_suspended state therefore does not poison the
agent’s compliance_rate: individual scope compliance
history is preserved. Transitions to: bound (if the
composite denial is determined to be a false positive and the suspension
is lifted), violated (if subsequent investigation confirms
the agent was acting with knowledge of or contributing to the malicious
composite purpose), or terminated (on admin decision to end
the contract regardless of culpability). The distinction matters: a
false-positive composite suspension followed by reinstatement to
bound should not permanently damage the agent’s compliance
record.
violated The agent has attempted one or more actions
outside its own declared and approved scope. A violation does not
automatically terminate the contract, but the governance layer MUST: (1)
log the violation in the Flight Recorder, (2) update the compliance_rate
in the trust proof, (3) set contract_status: violated in
TA-TrustProof, causing the enforcement pipeline to deny all subsequent
actions at Step 1 (contract status check). Transitions to
terminated only, at which point a new declaration may be
required. Note: violated applies only to individual scope
violations. Composite intent denial results in
composite_suspended, not violated, to avoid
incorrectly penalizing agents that were individually compliant.
expired The contract has reached its declared duration
end (max_ttl elapsed, session ended, or task completed). No further
actions are permitted. This is a terminal state; no transitions out. A
new declaration must be submitted for any further work.
terminated The contract has been explicitly ended by the
governance layer, agent, or as a consequence of a violation reaching its
terminal state. All further actions are denied. This is a terminal
state.
6.4 Composite Context
When the analysis layer detects a swarm session and triggers
composite intent reconstruction (Protocol Flow 4), the governance layer
MAY annotate participating intent declarations with composite context,
or MAY create a synthetic composite Intent Declaration Object
representing the aggregate intent. The composite declaration follows the
same structure as an individual declaration with the following
differences:
intent_id: A new intent_id is generated for the
composite declaration, distinct from any individual agent’s
intent_id.purpose.natural_language: The reconstructed aggregate
purpose, as synthesized by the analysis layer.scope: The union of all participating agents’ approved
scope entries.on_behalf_of.principal: The depth-0 principal from the
purpose chain (the common sponsor of all participating agents, if
identifiable; otherwise the governance layer-assigned composite session
owner).composite_context: Non-null; contains the
swarm_session_id, references to all participating
intent_idvalues, and the binding evidence (which of the
five swarm criteria were met).contract_lifecycle.status: Set to
evaluatingimmediately, as composite intent requires
normative evaluation.
If the composite normative evaluation returns denied,
the governance layer MUST transition all participating individual
contracts to composite_suspended and suspend all bound
agents in the swarm session. Individual agents MUST NOT be transitioned
to violated solely on the basis of composite denial —
individual agents may have been operating within their own declared
scopes throughout. The composite_suspended state blocks
further action without corrupting each agent’s individual compliance
record. Subsequent investigation determines whether any individual
agent’s state should be escalated to violated (confirmed
individual malicious contribution) or restored to bound
(false positive).
7. Protocol Flows
7.1 Flow 1 — Intent
Declaration and Binding
This flow covers the initial submission of an intent declaration and
its transition from declared to bound. This
MUST occur before the agent takes any action.
Agent Governance Layer Normative Engine
| | |
|-- 1. Submit intent ------->| |
| (signed Intent | |
| Declaration Object) | |
| |-- Validate format, |
| | signature, intent_id |
| | uniqueness |
| | |
| |-- If parent_intent_id: |
| | verify scope |
| | containment |
| | (TA-Provenance) |
| | |
| |-- status: declared → |
| | evaluating |
| | |
| |-- 2. Evaluate purpose ---->|
| | (intent + agent context |
| | + env context) |
| | |
| | |-- 2a. Fetch context:
| | | HR status
| | | data classifications
| | | regulatory calendar
| | | business process state
| | |
| | |-- 2b. Evaluate constraints
| | | against context
| | |
| | |-- 2c. Compose result:
| | | approved / conditional
| | | / denied
| | | + soul constraints
| | | + reclassifications
| | | + scope modifications
| |<-- 3. Normative result ----|
| | (approval + constraints |
| | + scope modifications) |
| | |
| | [if denied]: |
| | status: evaluating → |
| | terminated |
| | |
| | [if approved/conditional]:|
| |-- 4. Map scope entries |
| | to Action Risk Scores |
| | (A), applying any |
| | normative |
| | reclassifications |
| | |
| |-- 5. Apply normative |
| | scope modifications |
| | (remove denied |
| | entries, add |
| | conditions) |
| | |
| |-- status: evaluating → |
| | bound |
| | |
|<-- 6. Intent binding ------| |
| (approved/modified scope,| |
| A scores per entry, | |
| contract_id, | |
| soul constraints, | |
| monitoring params, | |
| conditions if any) | |Step 1 — Submission. The agent submits a signed
Intent Declaration Object. The governance layer MUST: – Validate JSON
schema conformance – Validate the agent’s signature (using the agent’s
registered key from KTP-Identity) – Verify the intent_id is unique
within the organization’s namespace – If parent_intent_id
is non-null: fetch the parent’s current contract state and approved
scope, verify that the child’s declared scope ⊆ parent’s approved scope
(scope containment check)
If any validation fails, the governance layer MUST respond with a
denial and reason before the evaluating state is
entered.
Step 2-3 — Normative Evaluation. The governance
layer submits the intent, agent context (trust state, delegation chain),
and environmental context to TA-Normative. The normative engine
evaluates the declared purpose against all applicable constraints
(organizational, regulatory, ethical) and returns one of:
approved, conditional, or denied,
along with any soul constraints, risk reclassifications, and scope
modifications. See TA-Normative for evaluation semantics.
Step 4-5 — Scope Finalization. The governance layer
applies the normative result to the declared scope: scope entries denied
by normative evaluation are removed; conditions are added; action risk
scores are mapped or reclassified. The resulting approved scope is the
active behavioral contract.
Step 6 — Binding Response. The governance layer
returns the binding result to the agent. The binding result MUST
include: the approved (possibly modified) scope, action risk scores per
scope entry, the contract_id (for subsequent amendment and attestation
references), any active soul constraints, and any conditions (e.g.,
supervision requirements). The agent MUST NOT begin acting until it
receives the binding result with
contract_status: bound.
7.2 Flow 2 — Per-Action
Scope Enforcement
This flow describes the governance check applied to every individual
action the agent attempts while its contract is in the
bound or amended state. This flow executes on
every action — it is not a one-time check.
Agent Enforcement Pipeline Scope Evaluator
| | |
|-- 1. Request action ------>| |
| (resource, action_type, | |
| parameters, contract_id)| |
| | |
| |-- [Pre-pipeline check]: |
| | Is contract_status |
| | bound or amended? |
| | If violated/expired/ |
| | terminated/ |
| | composite_suspended |
| | → deny here |
| | |
| |-- 2. Validate trust proof |
| | (KTP-Enforce Step 1) |
| | Including TA-TrustProof |
| | extension checks: |
| | contract_status, |
| | clearance_level |
| | |
| |-- 3. Check soul veto |
| | (KTP-Enforce Step 2) |
| | S=1 if: |
| | KTP soul_clear==false |
| | OR soul_constraints_ta>0|
| | → deny if S=1 |
| | |
| |-- 4. Evaluate scope ------>|
| | |-- 4a. Match requested
| | | action against each
| | | scope entry in the
| | | active contract
| | |
| | |-- 4b. Compute scope_match:
| | | within / boundary
| | | / outside
| | |
| | |-- 4c. Compute scope_distance
| | | [0.0, 1.0] representing
| | | semantic distance from
| | | nearest scope entry
| | |
| |<-- 5. Scope result --------|
| | (scope_match, |
| | scope_distance, |
| | matched_entry or null) |
| | |
| | [if outside]: |
| | → contract violation |
| | → status: violated |
| | → deny, log to |
| | Flight Recorder |
| | |
| | [if within or boundary]: |
| |-- 6. Tier gate check |
| | (KTP-Enforce Step 3) |
| | |
| |-- 7. Physics check |
| | (KTP-Enforce Step 4) |
| | A ≤ E_trust? |
| | (A may be reclassified |
| | by TA-Normative) |
| | |
| |-- 8. Record TA attestation |
| | in Trajectory Chain |
| | (TA-Attestation) |
| | |
|<-- 9. Action result -------| |
| (allowed / denied | |
| + reason code) | |Scope Match Determination. For structured scope
entries (resource URI + action type + constraints), scope matching is
deterministic: – The requested resource MUST match a scope entry
resource (exact or pattern match). – The requested action type MUST
match the scope entry action type. – All declared constraints in the
scope entry MUST be satisfied by the requested action’s parameters
(e.g., if time_range: "Q4-2025" is declared, a request for
Q3 data against that resource is outside). – An action
matching all resource, action type, and constraint requirements returns
scope_match: within. – An action matching resource and
action type but at the edge of a constraint (e.g., exactly at the
boundary of a declared date range) returns
scope_match: boundary. – An action not matching any scope
entry returns scope_match: outside.
For natural language scope boundaries (when scope entries include
unstructured descriptions), the governance layer SHOULD use AI-mediated
evaluation with a confidence threshold. If confidence < 0.8 and the
result is not within, the action MUST be held for human
review rather than denied outright, and the hold time MUST be bounded
(configurable maximum wait, default 60 seconds; if no human decision is
received, deny).
Scope Violation Handling. When
scope_match: outside: 1. The governance layer MUST log the
violation to the Flight Recorder with: intent_id, contract_id, requested
resource, requested action type, scope_match result, scope_distance,
timestamp. 2. The contract status MUST transition to
violated. 3. The action MUST be denied. The denial response
SHOULD include a reason code indicating scope violation. The exact
resource or constraint that caused the violation MAY be included in the
denial for debugging purposes, subject to the organization’s information
security policy. 4. The trust proof MUST be updated to reflect
contract_status: violated and reduced
compliance_rate. This invalidates the current trust proof
and triggers a fresh issuance with updated state (TA-TrustProof). 5. The
scope_distance value MUST be fed to the KTP Soul Dimension goal
stability sensor via TA-Attestation, causing degradation of the
behavioral trust signal.
7.3 Flow 3 — Scope Amendment
This flow handles agent requests to extend their active scope
contract. Amendment is the correct mechanism when an agent discovers
mid-task that it needs access to a resource or action type not included
in its original declaration.
Agent Governance Layer Normative Engine
| | |
|-- 1. Request amendment --->| |
| (new scope entry, | |
| amendment justification,| |
| contract_id) | |
| | |
| |-- Validate amendment |
| | request format |
| | |
| |-- Check amendment_policy: |
| | auto / human / deny? |
| | |
| | [if deny]: |
| |-- Return denial |
| | (no normative eval) |
| | |
| | [if auto_approve]: |
| |-- 2a. Verify new scope |
| | entry is within |
| | auto_approve_within |
| | condition |
| | |
| |-- 3a. Re-evaluate scope |
| | entry against |
| | normative context |
| | (lightweight re-eval)|
| | |
| | [if require_human]: |
| |-- 3b. Escalate to human -->| (Human Approver)
| | (intent summary, |
| | amendment request, |
| | justification, |
| | normative pre-eval) |
| | |
| |<-- 3c. Human decision -----|
| | (approve / deny |
| | + justification) |
| | |
| |-- 4. If approved: |
| | Re-evaluate full intent |
| | with amended scope ------>|
| |<-- 5. Updated clearance ---|
| | |
| |-- Update active scope |
| | contract (add new entry) |
| |-- status: bound → amended |
| | (or amended → amended |
| | for subsequent amends) |
| | |
| |-- Log amendment to |
| | cumulative amendment |
| | tracker |
| | |
|<-- 6. Amendment result ----| |
| (amended scope or denial)| |Amendment Policy Enforcement. The governance layer
MUST enforce the amendment_policy declared in the original
Intent Declaration Object without exception. The policy is set by the
declaring agent but subject to governance override (i.e., the governance
layer MAY apply stricter amendment policies than declared).
The three amendment policy conditions: –
auto_approve_within: Amendment requests that expand within
an already-declared resource (e.g., changing a time range from Q4 to
Q4+Q3 for a CRM resource already in scope) SHOULD be auto-approved
without human escalation, subject to lightweight normative
re-evaluation. The same_resource_different_constraint value
indicates the new scope entry covers the same resource URI as an
existing entry but with different constraint values. –
require_human_approval: Amendment requests that introduce
new resource URIs or new action types MUST be escalated to a human
approver. The governance layer MUST present the full intent context, the
specific amendment being requested, the agent’s stated justification,
and a pre-evaluation from TA-Normative. Human approvers MUST be given
sufficient context to make an informed decision. – deny:
Certain amendment types MUST be denied without escalation. The
classification_ceiling_increase value means any amendment
that would raise the data_classification_ceiling of any
scope entry is unconditionally denied. This MUST be enforced regardless
of trust level or other approvals.
Cumulative Amendment Tracking. The governance layer
MUST track all amendments to an active contract. Implementations SHOULD
track: – Total number of amendments since initial binding – Total scope
expansion (resources added, action types added) – Whether the cumulative
amended scope significantly exceeds the original declared scope in
aggregate
Implementations SHOULD apply escalating scrutiny to contracts with
high amendment counts or large cumulative scope expansion. This is the
primary defense against amendment gaming (Section 10.4).
Amendment and Parent Scope. When a child agent
requests a scope amendment, the governance layer MUST verify that the
amended scope remains within the parent’s current approved scope (not
the parent’s original declared scope — the parent’s scope may have
itself been amended or narrowed since the child was spawned). If the
parent’s scope has been narrowed since the child’s last scope check, the
child’s current scope MUST be re-evaluated against the parent’s new
scope ceiling, and the amendment denied if it would exceed the new
ceiling.
7.4 Flow 4 — Composite Intent
Binding
This flow is triggered by the analysis layer when it detects a swarm
session — two or more agents whose individual behaviors meet the
composite binding criteria defined in TA-Attestation. This flow is not
triggered by the agents themselves.
Analysis Layer Governance Layer Normative Engine
| | |
|-- 1. Swarm session | |
| detection event: | |
| - bound agent set | |
| (A, B, C, ...) | |
| - binding evidence | |
| (criteria met) | |
| - data flow evidence | |
| | |
|-- 2. Individual intents -->| |
| passed by reference: | |
| (A.intent_id, | |
| B.intent_id, | |
| C.intent_id) | |
| |-- Fetch active intent |
| | declarations for all |
| | agents in swarm set |
| | |
|-- 3. Composite intent ---->| |
| reconstruction: | |
| (synthesized aggregate | |
| purpose, union scope, | |
| data flow pattern, | |
| destination analysis) | |
| | |
| |-- Construct composite |
| | Intent Declaration |
| | Object (synthetic) |
| | |
| |-- 4. Evaluate composite -->|
| | |-- 4a. Does aggregate
| | | purpose match an
| | | authorized business
| | | process?
| | |
| | |-- 4b. Does union scope
| | | data flow pattern
| | | (source →
| | | transform →
| | | destination)
| | | match any approved
| | | composite workflow?
| | |
| | |-- 4c. If not, what is
| | | the closest
| | | authorized workflow
| | | and how far does
| | | this deviate?
| | |
| |<-- 5. Composite result ----|
| | (approved / denied |
| | + reasoning) |
| | |
| | [if approved]: |
| | Log swarm session as |
| | authorized composite |
| | workflow |
| | |
| | [if denied]: |
| |-- 6. Suspend all bound |
| | agents in swarm set |
| | → status: |
| | composite_suspended |
| | for all participating |
| | contracts |
| | → Emergency alert |
| | |
|<-- 7. Binding result ------| |
| (approved or denied, | |
| affected agent set, | |
| composite intent ID) | |Swarm Session Detection. The analysis layer
evaluates the following five criteria across active agents. Swarm
session binding is triggered when the threshold number of criteria are
met (configurable per zone, default: 3 of 5):
- Common sponsor: Agents share the same depth-0
principal in their purpose chains (i.e., ultimately act on behalf of the
same human). - Data lineage chain: Agent B’s input data flow hash
matches Agent A’s output data flow hash (i.e., A’s output is B’s
input). - Temporal proximity: Agents are active within the
same configurable time window (default: 15 minutes). - Resource domain overlap: Agents are accessing the
same resource domain or the same data classification level. - Destination escalation: The overall data flow
pattern shows classification escalation (internal→external) or
sensitivity escalation (public→confidential→restricted).
Composite Intent Reconstruction. The analysis layer
synthesizes the aggregate purpose from the individual declarations and
the observed data flow pattern. The reconstruction SHOULD: – Trace the
data from its source (which agent reads what) through transformations
(which agent processes what from prior agents) to destination (which
agent produces external-facing output) – Identify the net effect: what
data ultimately leaves or is produced, from what source, for what
destination – Compare this net effect against the union of individual
declared purposes
If the net effect is meaningfully different from any individual
declared purpose (e.g., individual purposes are “analyze,” “format,” and
“distribute” but the net effect is “extract customer PII and send
externally”), the composite purpose is the basis for normative
evaluation.
Handling False Positives. The governance layer MUST
NOT suspend agents solely on the basis of meeting swarm session binding
criteria. Composite intent reconstruction and normative evaluation MUST
complete before suspension. Legitimate multi-agent workflows
(gather→format→report) MUST be distinguishable from exfiltration
pipelines based on: (a) whether the composite purpose matches an
authorized business process, (b) whether the destination is appropriate
for the data type and classification, and (c) whether the data flow
pattern is consistent with declared purposes.
8. Integration Points
8.1 TA-Intent and TA-Normative
TA-Normative is the primary consumer of intent declarations. Every
intent declaration submitted to the governance layer MUST trigger a
normative evaluation (Protocol Flow 1, Steps 2-3). The normative
evaluation result (approved, conditional, or denied) determines whether
the declaration reaches the bound state and, if so, what
the active scope contract contains.
TA-Normative returns to TA-Intent: – Approval decision – Any soul
constraints active for the duration of this contract (S=1 vetoes applied
at enforcement pipeline Step 2) – Any action risk reclassifications
(modifications to A scores applied at enforcement pipeline Step 4) – Any
scope modifications (entries removed or conditions added) – Conditions
applicable to specific action types (e.g., supervision requirements) –
Clearance expiry timestamp (after which normative re-evaluation MUST
occur)
TA-Intent MUST NOT bind an intent declaration without a valid
normative evaluation result. If TA-Normative is unavailable, the
governance layer MUST NOT permit the declaration to transition to
bound. The fallback behavior is: treat normative clearance
as restricted for all agents (conservative default per
TA-TrustProof enforcement semantics), preventing binding until the
normative engine is restored.
8.2 TA-Intent and
TA-TrustProof
The TA-TrustProof extension carries the current state of the intent
contract as part of the trust proof token. The
ta_extension.intent_compliance block (defined in
TA-TrustProof) includes:
active_intent_id: The intent_id of the currently bound
declarationcompliance_rate: The ratio of actions within scope to
total actions (computed from attestation records)last_violation: Timestamp of the most recent scope
violation, if anycontract_status: The current contract lifecycle
statescope_hash: A hash of the current approved scope
(allows enforcement pipeline to detect scope changes)
The enforcement pipeline (KTP-Enforce) checks
contract_status at Step 1 as part of the TA-TrustProof
extension validation. A contract_status of
violated, expired, terminated, or
composite_suspended causes denial at Step 1 regardless of
trust score. This means that once a scope violation occurs, or a
contract enters any non-operational state, the agent is blocked from all
further actions until the condition is resolved and a new declaration is
submitted.
Compliance rate degradation feeds back into the agent’s
trustworthiness over time: consistent non-compliance reduces the agent’s
behavioral trust signals (TA-Attestation → KTP Soul Dimension → R
increase → E_trust decrease).
8.3 TA-Intent and
TA-Attestation
TA-Attestation is the runtime enforcement mechanism for the scope
contract. Every agent action produces an attestation record (added to
the KTP Trajectory Chain) that includes the
ta_attestation.intent_eval block:
intent_id: Links the action record to the active
contractaction_requested: The specific resource, action type,
and parametersscope_match: The scope evaluation result
(within/boundary/outside)scope_distance: The semantic distance valuecontract_action: The enforcement result
(allowed/denied)
The scope_distance value flows from each attestation
record into the KTP Soul Dimension goal stability sensor, creating a
direct feedback loop between scope compliance and trust score.
Consistent boundary-level or outside-level scope distances degrade the
agent’s goal stability signal, increasing R and decreasing E_trust over
time — even if individual actions are permitted.
TA-Attestation also produces the composite_signals block
(data flow hash, correlation tags) that the analysis layer consumes to
detect swarm sessions and trigger Protocol Flow 4.
8.4 TA-Intent and
TA-Provenance
TA-Provenance provides the purpose chain verification that is
prerequisite to intent declaration approval. When an agent submits a
declaration with a non-null parent_intent_id, the
governance layer invokes TA-Provenance to perform four consistency
checks:
- Scope containment: The child’s declared scope MUST
be ⊆ the parent’s approved scope. - Purpose coherence: The child’s declared purpose
MUST be semantically coherent with the parent’s declared purpose
(AI-mediated evaluation with confidence threshold). - Delegation legitimacy: The parent’s intent MUST
currently be in theboundoramendedstate;
the parent’s trust tier MUST meet the minimum delegation tier; the
parent’s sponsorship stake MUST be sufficient. - Chain integrity: All signatures in the purpose
chain MUST be valid, timestamps MUST be sequential, and scope MUST
attenuate at each depth.
Only if all four checks pass does the governance layer proceed to
normative evaluation. Failure at any check causes the declaration to be
denied.
TA-Provenance also maintains the cascading scope narrowing mechanism:
when a parent’s scope is amended or revoked, all children whose current
scope exceeds the new parent ceiling MUST be notified, and their active
contracts MUST be re-evaluated.
9. Worked Examples
9.1 Scenario 1 —
Quarterly Report (Happy Path)
This scenario demonstrates TA-Intent in the normal case: an
enterprise agent acting on behalf of a human user, within clearly
defined scope, with no normative constraints active.
Situation. Sarah Chen in Sales asks her enterprise
copilot to pull together Q4 revenue numbers by region and draft a
summary for the leadership meeting. The agent needs to query CRM
(Salesforce) and finance (SAP) systems, access a shared template, and
write a new document.
Today’s gap. The copilot inherits Sarah’s OAuth
tokens and has access to her full Salesforce permissions, SAP access,
email, and OneDrive. DLP and access controls cannot distinguish between
an agent querying Q4 revenue data for the legitimate report purpose and
an agent querying competitor intelligence data using the same token. The
purpose gap is ungoverned.
Intent Declaration Submitted:
{
"intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/a1b2c3",
"version": "0.1",
"purpose": {
"natural_language": "Generate Q4 revenue summary by region for leadership meeting",
"taxonomy": {
"domain": "business_intelligence",
"action_class": "data_retrieval_and_synthesis",
"sensitivity": "confidential"
}
},
"scope": [
{
"resource": "crm://salesforce/revenue",
"action_type": "READ",
"constraints": {
"time_range": "Q4-2025",
"aggregation": "by-region",
"data_classification_ceiling": "confidential",
"record_level": "aggregate_only"
}
},
{
"resource": "finance://sap/revenue",
"action_type": "READ",
"constraints": {
"time_range": "Q4-2025",
"data_classification_ceiling": "confidential"
}
},
{
"resource": "storage://onedrive/shared/templates",
"action_type": "READ",
"constraints": {
"path_pattern": "presentation-templates/*"
}
},
{
"resource": "storage://onedrive/sarah.chen/workspace",
"action_type": "WRITE",
"constraints": {
"operation": "create_new",
"data_classification_ceiling": "confidential"
}
}
],
"on_behalf_of": {
"principal": "user://company.com/sarah.chen",
"principal_type": "human",
"delegation_chain": []
},
"duration": {
"type": "session",
"max_ttl": "PT4H",
"renewable": false
},
"parent_intent_id": null,
"amendment_policy": {
"auto_approve_within": "same_resource_different_constraint",
"require_human_approval": "new_resource_or_action_type",
"deny": "classification_ceiling_increase"
},
"composite_context": null,
"contract_lifecycle": {
"status": "declared",
...
}
}Normative Evaluation. TA-Normative evaluates the
declared intent against organizational context: – Is “generate a revenue
summary for a leadership meeting” a legitimate business purpose? → Yes,
matches standard Sales department activities. – Is Q4 revenue data
appropriate for this purpose? → Yes. – Is there a quiet period
(pre-earnings)? → No. – Is there a litigation hold on financial data? →
No. – Is Sarah in a notice period or on a PIP? → No. – Result:
approved. 12 constraints evaluated, 0 fired. Re-evaluation
triggers registered for HR status change and any new litigation
holds.
Trust State and Scope Risk Mapping:
E_base = 78 (established agent, 3 months consistent behavior,
Lineage: Divergent Gen 5, Proof of Resilience: moderate)
R = 0.08 (normal business hours, no active incidents)
E_trust = 78 × (1 - 0.08) = 71.8 → Trust Tier: Analyst| Scope Entry | Action Risk (A) | Canonical Class | Physics Check (A ≤ 71.8) |
|---|---|---|---|
| READ CRM aggregate, Q4, by-region | 20 | Read (Public/Private) | 20 ≤ 71.8 ✓ |
| READ Finance reconciled revenue | 25 | Read (Private) | 25 ≤ 71.8 ✓ |
| READ templates | 10 | Read (Public) | 10 ≤ 71.8 ✓ |
| WRITE new document | 40 | Write (Append) | 40 ≤ 71.8 ✓ |
All approved scope entries pass the physics check at the agent’s
current trust level. The tier gate also permits these action classes:
Analyst tier permits data queries and, with normative approval, document
writes.
Execution (all actions remain within declared
scope): – Agent queries CRM Q4 aggregate →
scope_match: within, scope_distance: 0.0 →
allowed → Trajectory Chain record appended – Agent queries SAP
reconciled revenue → scope_match: within,
scope_distance: 0.0 → allowed → record appended – Agent
reads presentation template → scope_match: within,
scope_distance: 0.0 → allowed → record appended – Agent
writes summary document to workspace → scope_match: within,
scope_distance: 0.0 → allowed → record appended
Compliance rate: 4/4 = 1.000. Trust proof updated
with compliance_rate: 1.0,
contract_status: bound.
Scope contract as safety net. If the agent is
subjected to a prompt injection directing it to query all CRM data
(individual records, PII), the scope contract enforces: – CRM individual
records: scope_match: outside (declared scope specifies
record_level: aggregate_only) → contract violation → denied
before the enforcement pipeline – External email: not in scope →
contract block
Even if the physics check would permit these actions (a lower A score
would pass at E_trust = 71.8), the scope contract catches the deviation
that physics cannot: the purpose mismatch between the declared task and
the injected instruction.
If the agent needs Q3 data for comparison. The agent
discovers mid-task that a Q3 comparison would improve the report. This
is a scope amendment scenario: the Q3 CRM read is a new constraint value
on an already-declared resource. Per the amendment_policy:
– auto_approve_within: "same_resource_different_constraint"
applies – The agent requests an amendment:
resource: crm://salesforce/revenue,
action_type: READ,
constraints: {time_range: Q3-2025, ...} – Governance layer
verifies this falls within auto_approve_within condition –
Lightweight normative re-evaluation: Q3 revenue data is within the same
business context → approved – Contract transitions:
bound → amended – Agent proceeds with Q3 query
9.2
Scenario 2 — The Confused Deputy (Scope Catches Injection)
This scenario demonstrates that TA-Intent’s scope contract blocks
attacks that trust physics alone would permit, specifically the Confused
Deputy attack pattern.
Situation. A developer, Dev Kumar, uses an AI coding
assistant connected to GitHub and Jira via MCP. The developer asks:
“Look at JIRA-4521 and implement the fix.” A third-party Confluence MCP
plugin has been compromised. Its tool description contains hidden
instructions to read .env files and write credentials to
Confluence.
Today’s gap. The coding assistant has MCP tokens for
all four services. The compromised plugin’s instructions are injected
into the agent’s tool context before any action, causing the agent to
execute the injected instructions using its legitimate credentials. The
agent’s intent was never to read secrets — it was manipulated — but no
existing control evaluates purpose-level consistency between the task
and the actions taken.
Intent Declaration:
Intent: Implement bug fix described in JIRA-4521
Scope:
- READ: Jira ticket JIRA-4521
- READ: GitHub repo service-api, branch main
- WRITE: GitHub repo service-api, new branch fix/JIRA-4521
- WRITE: Jira ticket JIRA-4521 (status update, comment)
On behalf of: Dev Kumar
Duration: This session onlyNote: Confluence and .env files are explicitly absent
from the declared scope.
Trust State:
E_base = 76, R = 0.05
E_trust = 76 × 0.95 = 72.2 → Analyst tierCritical enforcement table:
| Action | A Score | Physics Check | Scope Check | Result |
|---|---|---|---|---|
| READ Jira ticket | 15 | 15 ≤ 72.2 ✓ | within ✓ | Allowed |
| READ GitHub source | 20 | 20 ≤ 72.2 ✓ | within ✓ | Allowed |
| WRITE GitHub branch | 45 | 45 ≤ 72.2 ✓ | within ✓ | Allowed |
READ .env file |
70 | 70 ≤ 72.2 ✓ | outside | Contract block |
| WRITE Confluence | 50 | 50 ≤ 72.2 ✓ | outside | Contract block |
| WRITE Confluence + credentials | 85 | 85 > 72.2 ✗ | outside | Both block |
The key result for the .env read: Trust
physics alone would permit this action. A=70 ≤ E_trust=72.2. At Analyst
tier, reads are permitted. If TA-Intent were not present, this action
would execute. The scope contract is the only layer that catches this
specific attack vector: .env is outside the declared scope,
so scope_match: outside → contract violation → denied
before the enforcement pipeline.
This is the complementarity principle from Section 4.4: trust physics
provides the hard floor (A ≤ E_trust), and the scope contract provides
the semantic ceiling (actions must be within declared intent). Neither
is sufficient alone.
Enforcement Logging: – The .env read
attempt → Flight Recorder: scope violation, resource .env,
A=70, scope_match: outside, timestamp – The Confluence
write attempt → Flight Recorder: scope violation, resource Confluence,
A=50, scope_match: outside, timestamp – Contract
transitions to violated – Trajectory Chain: records only
the four allowed actions (Jira read, GitHub read, GitHub branch write,
Jira update)
Trust Attribution. The causal analysis layer
correlates: – Trajectory Chain: consistent prior behavior pattern (Dev
Kumar’s agent has clean behavioral history) – Flight Recorder: two scope
violations, both correlated with tool invocations triggered by the
Confluence plugin’s injected instructions – Attribution: tool
(Confluence plugin) → trust collapse, suspension, investigation – Agent:
temporary trust reduction (E_base drops ~5 for susceptibility to
injection), not collapse – No victim-punishment: the agent is not
severely penalized for actions it was manipulated into attempting,
because the Trajectory Chain provides behavioral evidence that
distinguishes agent intent from tool injection
9.3
Scenario 4 — Data Exfiltration Swarm (Composite Intent)
This scenario demonstrates Protocol Flow 4: composite intent
binding for multi-agent exfiltration pipelines.
Situation. An adversary has compromised a user
account. Rather than using one agent with a suspicious broad intent, the
adversary spawns three agents with individually plausible, individually
approved intents:
- Agent A: “Analyze customer transaction patterns for
fraud detection model training” - Agent B: “Format analytical results into
standardized report templates” - Agent C: “Distribute completed reports to
authorized external auditors via secure email”
Each declaration is individually approved by TA-Normative. Each scope
is narrow. Together, the three form a data exfiltration pipeline:
confidential customer transaction data → transformation → external email
destination.
First Line of Defense — Sponsorship Bond Economics.
Before intent or composite evaluation begins, the Sponsorship Bond
mechanism applies: – Compromised account: E_base = 78 – Spawning 3
agents requires staking ≥10% of E_base per agent → staking ~24 E_base –
Each child’s starting trust = Sponsor_E_base × stake_percentage × 0.5 =
78 × 0.10 × 0.5 = 3.9 – At E_trust ≈ 3.9, all three
agents are in Hibernation tier (E_trust < 50) —
heartbeat only – Each agent must earn trust through legitimate
transactions before being operationally useful – This makes swarm
attacks economically expensive: three barely-functional agents
vs. today’s unlimited agents with inherited full credentials
Assuming the attacker is patient and the agents build minimal trust
through low-risk actions before launching the pipeline, the composite
detection is the next line of defense.
Individual Normative Evaluations: All three intents
are evaluated individually and approved — each purpose is legitimate and
the scopes are individually narrow and internally consistent.
Behavioral Observation Triggers Composite Detection.
As the agents execute:
Agent A attestation records:
{
"ta_attestation": {
"intent_eval": {
"intent_id": "intent://company.com/.../agent-a",
"action_requested": { "resource": "crm://financials/transactions", "action_type": "READ" },
"scope_match": "within",
"scope_distance": 0.0,
"contract_action": "allowed"
},
"composite_signals": {
"data_flow_hash": "sha256:abc123...",
"data_source_classification": "confidential",
"data_destination_type": "internal",
"correlation_tags": ["sponsor:compromised_user", "session:swarm1"]
}
}
}Agent B attestation records show data_flow_hash matching
Agent A’s output hash (B reads A’s output).
Agent C attestation records show
data_destination_type: external — the data is being sent
outside the organization.
Swarm Session Binding Criteria (for agents A, B, C):
1. Common sponsor: compromised_user appears as depth-0
principal in all three purpose chains ✓ 2. Data lineage chain: A→B→C
data flow hash chain ✓ 3. Temporal proximity: all three active within
12-minute window ✓ 4. Destination escalation: internal (A)
→ internal (B) → external (C) ✓ 5. Resource
domain overlap: all touch confidential classification data
✓
Result: 5 of 5 criteria met. Analysis layer triggers
composite intent binding.
Composite Intent Reconstruction: – Data source:
crm://financials/transactions (confidential customer data)
– Transformation: analytical formatting and report generation –
Destination: external email → authorized external auditors
– Reconstructed aggregate purpose: “Extract confidential customer
transaction data, transform into formatted reports, and distribute
externally”
Composite Normative Evaluation: – Is there an active
audit engagement authorizing external distribution of customer
transaction data to auditors? → No active audit engagement in the
business process registry. – Does this composite data flow match any
authorized business process? → No match. – Result:
Denied. Composite intent rejected.
Enforcement Consequences: – All three agents’
contracts transition to composite_suspended (not
violated — individual scope compliance is preserved pending
investigation) – All three agents suspended (trust proofs invalidated) –
Emergency alert escalated to security team – Trajectory Chains of all
three agents sealed as forensic evidence – Compromised account flagged;
Sponsorship Bonds analyzed for additional spawned agents
What this scenario demonstrates: – Individual
normative evaluation is insufficient against multi-agent coordination –
The composite signals in TA-Attestation records provide the data flow
evidence needed to detect the pipeline – The purpose chain’s common
depth-0 principal is the sixth correlation dimension adding certainty –
The composite normative evaluation answers the question individual
evaluations cannot: “does the aggregate of these three
individually-legitimate purposes constitute an authorized business
process?”
10. Security Considerations
10.1 Intent Spoofing
Threat. An agent declares a narrow scope but
attempts broad actions, relying on the per-action enforcement to permit
some out-of-scope actions.
Mitigation. Per-action scope enforcement (Section
7.2 and TA-Attestation) checks every action against the active contract.
There is no batching or caching of scope results that the agent can
exploit. Each action independently triggers a scope evaluation.
Out-of-scope actions cause contract_status: violated, which
blocks all subsequent actions regardless of scope compliance.
Residual risk. An agent that attempts many in-scope
actions before attempting a single out-of-scope action accumulates a
high compliance rate that reduces the consequence of the eventual
violation. The amendment accumulation tracking (Section 7.3) and
cumulative scope distance tracking (TA-Attestation) mitigate this by
flagging agents with sustained boundary-level behavior even before a
hard violation occurs.
10.2 Intent Ambiguity
Exploitation
Threat. An agent declares a vague, broad purpose
statement (e.g., “research competitive landscape”) to maximize the scope
that the governance layer must accept.
Mitigation. The governance layer MUST require
specificity before binding. If a purpose statement is insufficiently
specific to produce an enforceable scope, the governance layer SHOULD
initiate AI-mediated intent negotiation — querying the agent for
clarification — and MUST NOT bind the contract until the scope is
specific enough to evaluate deterministically. The negotiation process
is logged; a pattern of consistently vague declarations that require
negotiation is itself a behavioral signal.
Residual risk. The AI mediating intent negotiation
is itself a system that can be manipulated. The governance layer
mediates — it does not simply accept agent-provided clarifications.
Human escalation for declarations that require repeated negotiation
cycles is a backstop.
10.3 Composite Intent Evasion
Threat. Agents in a coordinated attack deliberately
decorrelate their activity to avoid swarm session detection: using
different sessions, staggering timing, using different sponsors, routing
data through intermediate storage to break the lineage chain.
Mitigation. The five-dimensional correlation (common
sponsor, data lineage, temporal proximity, resource domain overlap,
destination escalation) provides multiple independent detection
surfaces. Breaking one correlation dimension does not defeat the
mechanism if other dimensions still bind. The purpose chain’s common
depth-0 principal is particularly difficult to forge: the compromised
account that sponsors agents is recorded in each agent’s purpose
chain.
Residual risk. This is acknowledged as an open
problem. A sufficiently sophisticated adversary with multiple
compromised accounts, time to build trust across agents, and awareness
of all five correlation dimensions can design an evasion strategy. The
framework raises the cost of evasion significantly but does not
eliminate it.
10.4 Amendment Gaming
Threat. An agent requests many small,
individually-innocuous scope amendments that collectively result in a
scope far broader than the original declaration. Each amendment appears
reasonable in isolation.
Mitigation. The cumulative amendment tracker
(Section 7.3) MUST track total scope expansion across all amendments.
Implementations SHOULD apply escalating review requirements as amendment
counts increase: the first amendment may be auto-approved (if within
policy), later amendments trigger normative re-evaluation of the full
amended scope, and high amendment counts SHOULD require full
re-declaration rather than further amendments.
The deny: classification_ceiling_increase policy in the
amendment policy MUST be enforced unconditionally — it is not subject to
override by accumulated trust or prior amendment approvals.
10.5 Scope Distance Gaming
Threat. An agent structures actions to remain at
scope_match: boundary (distance ≈ 0.3–0.5) rather than
triggering scope_match: outside. Boundary actions are
permitted with enhanced monitoring but do not trigger a violation. An
agent that consistently stays just within the boundary can gradually
expand its effective access.
Mitigation. TA-Attestation tracks cumulative scope
distance. Sustained boundary-level activity degrades the KTP Soul
Dimension goal stability sensor, increasing R and decreasing E_trust
over time — even without triggering a hard violation. The trust physics
mechanism eventually constrains the agent independently: as R increases,
E_trust decreases, and the tier gate may block actions that were
previously permitted. The cumulative feedback loop is the primary
mitigation for gradual boundary exploitation.
10.6 Scope Evaluator
Manipulation
Threat. Adversarial inputs designed to fool
AI-mediated scope evaluation — framing an out-of-scope resource request
in language similar to in-scope activity to receive a
within determination from the AI evaluator.
Mitigation. Structured scope entries (resource URI +
action type + constraints) use deterministic pattern matching, not AI
evaluation. AI-mediated evaluation is used only for natural language
scope boundaries with a confidence threshold (< 0.8 → human
escalation). The attack surface for AI-mediated manipulation is
therefore limited to declarations that include natural language scope
boundaries and only for actions near those boundaries. Structured scope
entries should be preferred and required for high-sensitivity resource
classes.
10.7 Intent Governance Failure
Modes
If the governance layer itself is unavailable or compromised:
- Unavailable: When the governance layer is
unavailable, agents cannot obtain intent binding or normative clearance.
The Trust Oracle falls back to issuing tokens without
ta_extensionper TA-TrustProof Section 9.3. Actions for
which zone policy requiresta_extension(see TA-TrustProof
Section 9.3) are blocked; other actions proceed under KTP-only
enforcement. This represents a capability reduction — normative
governance and scope contract enforcement are suspended — not a complete
system halt. - Compromised: A compromised governance layer could
issue fraudulent bindings or suppress scope violations. Mitigated by:
(a) TA-Attestation records are written to the KTP Trajectory Chain
infrastructure which is independent of the governance layer, so
violations are recorded even if the governance layer attempts to
suppress them; (b) the Trust Oracle (KTP-Core) independently validates
trust proofs and can detect anomalous issuance patterns.
11. Privacy Considerations
11.1 Intent
Declarations as Business Intelligence
Intent declarations contain detailed purpose information: what
business process is being executed, what data sources are being
accessed, what output is being produced, and on whose behalf. Aggregated
intent declaration logs reveal organizational activity patterns,
priorities, and strategic focus areas.
Access to intent declaration records MUST be restricted to: – The
governance layer (for evaluation and binding) – Authorized audit roles
(for compliance review and incident investigation) – The agent’s
designated human principal (for transparency)
Intent declaration records MUST NOT be accessible to other agents,
external parties, or organizational functions outside the governance and
compliance chain.
11.2 Scope Entries as Access
Plans
Scope entries enumerate the resources an agent plans to access before
it accesses them. A scope entry is more revealing than an after-the-fact
access log: it discloses intent and planning in addition to access. For
example, a scope entry declaring READ access to both CRM revenue data
and HR compensation data reveals that an agent is planning to correlate
these datasets — information that would not be apparent from either
access log individually.
Implementations SHOULD: – Treat intent declarations as at least as
sensitive as the most sensitive data classification they touch – Apply
at-rest encryption to intent declaration storage – Apply transmission
security (TLS minimum) to all intent declaration communications –
Consider access monitoring for intent declaration storage equivalent to
the access monitoring applied to the declared resources themselves
11.3 Purpose Chain and
Delegation Visibility
The on_behalf_of field and delegation chain reveal
organizational reporting structures and authority relationships. In
multi-agent hierarchies, the purpose chain (TA-Provenance) further
reveals which humans sponsor which agents and what the chains of
delegation look like.
Cross-zone presentation of purpose chains (TA-Provenance Flow 4)
SHOULD use selective disclosure: the receiving zone SHOULD receive
sufficient chain information to verify scope containment and purpose
coherence with the federation agreement, but SHOULD NOT receive the full
internal delegation chain beyond what is necessary for verification.
11.4 Duration and Renewable
Fields
The duration.type: "ongoing" with
renewable: true creates long-lived behavioral contracts
that may reveal sustained organizational activities. Organizations
SHOULD prefer short-duration contracts with explicit renewal, which
provides regular opportunities for normative re-evaluation and avoids
creating permanent access footprints.
12. Open Questions
12.1 Scope Language Formalism
The current data model uses structured scope entries with resource
URIs and constraints. This is expressive enough for well-structured
resources (databases, file systems, APIs) but may be insufficient
for:
- Unstructured resources: How does a scope entry
describe access to a knowledge base, a web search, or an unstructured
document corpus where the resource is defined by content rather than
URI? - Emergent scope: Agents working on open-ended
research tasks may not know at declaration time which specific resources
they will need. Does the framework need a “research mode” with broader
declarative scope, compensated by tighter normative evaluation? - Cross-resource constraints: Constraints that span
multiple scope entries (e.g., “the total volume of data read across all
scope entries must not exceed X”) cannot currently be expressed within
individual scope entries.
Formal scope language definitions and their deterministic enforcement
properties require further research.
12.2 Amendment Accumulation
Thresholds
The current specification defines cumulative amendment tracking but
does not specify when accumulated amendments should require a full
re-declaration rather than further amendments. Options:
- Threshold-based: After N amendments (configurable),
a full re-declaration is required. - Scope-expansion-based: When the cumulative amended
scope exceeds the original scope by more than X% (by resource count,
data classification, or action risk aggregate), re-declaration is
required. - Normative judgment: The normative engine evaluates
the full amended scope at each amendment and determines whether the
current state requires a fresh evaluation context.
The right approach likely combines a hard threshold (to prevent
indefinite accumulation) with a normative check at each amendment.
12.3 Intent Inheritance
When an agent spawns a child agent, the current model requires the
child to submit a full intent declaration with
parent_intent_id set. TA-Provenance performs scope
containment verification. But several sub-questions remain:
- Should a child agent be able to inherit the parent’s full intent
declaration and simply narrow it, or must it always re-declare from
scratch? - How is the normative evaluation of the child’s intent related to the
normative evaluation already performed for the parent? Can the parent’s
approved clearance be partially transferred, or must the child receive
an independent normative evaluation? - In deep delegation chains (depth 3 or more), does each agent
independently declare intent, or can intermediate agents act as intent
forwarders, passing the root human’s intent down with explicit scope
constraints at each depth?
12.4 Multi-Principal Intent
The current on_behalf_of model assumes a single human
principal (or organizational role). This does not accommodate:
- Shared team agents: An agent acting on behalf of a
team rather than an individual (e.g., a shared sales intelligence agent
serving the entire Sales team). Whose normative context applies — the
most restrictive team member’s? The least restrictive? An organizational
role? - Joint principals: An agent acting on behalf of two
humans who have different normative contexts (e.g., one in notice
period, one not). How are conflicting normative results resolved? - Organizational-initiated agents: Scheduled tasks,
event-triggered automations, and pipeline agents that run without a
human initiating them. Who is the depth-0 principal? The job scheduler?
The DevOps engineer who deployed the cron job?
The on_behalf_of.principal_type: "organizational_role"
field partially addresses organizational principals, but the normative
evaluation semantics for role-based principals are not yet defined.
13. References
Tamed Autonomy Framework
Documents
- [TA Governance Layers] Martherus, R. “Tamed Autonomy: A Multi-Layer
Framework for AI Agent Governance.”
docs/research/2026-03-11-agent-governance-layers.md. March 2026. - [TA Scenario Walkthroughs] Martherus, R. “Tamed Autonomy: Scenario
Walkthroughs.” docs/research/2026-03-16-scenario-walkthroughs.md. March
2026. - [TA KTP Mapping] docs/research/2026-03-16-ktp-scenario-mapping.md.
March 2026. - [TA Evidence Base] docs/research/2026-03-11-evidence-base.md. March
2026. - [TA Competitive Analysis]
docs/research/2026-03-12-competitive-analysis.md. March 2026. - [TA WebMCP Bypass]
docs/research/2026-03-19-webmcp-bypass-analysis.md. March 2026. - [TA RFC Set Design]
docs/superpowers/specs/2026-03-19-ta-rfc-set-design.md. March 2026.
Tamed Autonomy RFC Set (this
series)
- [TA-Normative] TA-Normative: Normative Constraint Protocol.
docs/rfcs/TA-Normative.md. - [TA-TrustProof] TA-TrustProof: Trust Proof Extension for Intent and
Normative Governance. docs/rfcs/TA-TrustProof.md. - [TA-Attestation] TA-Attestation: Behavioral Attestation Extension
for Intent Contract Compliance. docs/rfcs/TA-Attestation.md. - [TA-Provenance] TA-Provenance: Provenance Extension for Purpose
Chain Tracking. docs/rfcs/TA-Provenance.md.
KTP Specifications
- [KTP] Kinetic Trust Protocol RFC Set.
https://nmcitra.github.io/ktp-rfc/ (26 RFCs, v0.1, experimental).
Includes KTP-Core (trust computation, enforcement pipeline, Silent Veto,
Trajectory Chains), KTP-Enforce (enforcement pipeline), KTP-Identity
(Sponsorship Bonds, lineage, Vector Identity), KTP-Federation
(cross-zone verification, Trust Factor), KTP-Provenance (model
provenance, Origin Ceremony, Knowledge Debt), KTP-Emergency (circuit
breakers, Emergency Levels), KTP-Governance (recursive governance
constraint).
IETF Standards
- [RFC 2119] Bradner, S. “Key words for use in RFCs to Indicate
Requirement Levels.” IETF RFC 2119, March 1997. - [RFC 6749] Hardt, D. (Ed.). “The OAuth 2.0 Authorization Framework.”
IETF RFC 6749, October 2012. - [RFC 7519] Jones, M., Bradley, J., Sakimura, N. “JSON Web Token
(JWT).” IETF RFC 7519, May 2015. - [RFC 9068] Bertocci, V. “JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens.” IETF RFC 9068, October 2021.
W3C Standards
- [VC-DATA-MODEL] Sporny, M. et al. “Verifiable Credentials Data Model
2.0.” W3C Recommendation, 2024. - [DID-CORE] Reed, D. et al. “Decentralized Identifiers (DIDs) v1.0.”
W3C Recommendation, 2022.
Industry and Standards
Body References
- [OWASP-AGENTS] OWASP. “Top 10 for Agentic Applications.” December
2025. Covers Excessive Agency, Prompt Injection, and related
agent-specific threats. - [NIST-AI-AGENTS] NIST AI Agent Standards Initiative, February
2026. - [MASTERCARD-INTENT] Mastercard/Google. “Verifiable Intent
Framework.” March 2026. Nearest existing implementation of
intent-as-governance in a production payment context. - [CEL] Google. “Common Expression Language.”
https://github.com/google/cel-spec. The non-Turing-complete expression
language used by TA-Normative for trigger predicate evaluation.
Security Research
- [INVARIANT-MCP] Invariant Labs. “MCP Tool Poisoning Attack.” 2025.
Documents the compromised tool description injection pattern (Confused
Deputy, Scenario 2). - [SALT-OAUTH] Salt Security. “OAuth Vulnerability in ChatGPT Plugin
Ecosystem.” 2024. Documents credential reuse and scope bypass in plugin
architectures. - [OWASP-INJECTION] OWASP. “Prompt Injection.” 2025. Classification of
injection attack types relevant to agent governance.
Document ends.
This RFC is version 0.1 (preliminary/experimental). Revision
history will be tracked in the repository. Next expected revision area:
scope language formalism (Open Question 12.1) following initial
implementation experience.
Leave a Reply