Current protocols govern who can act. These RFCs govern why — and whether they should.
The Problem
Current AI agent integration protocols (MCP, OAuth, RBAC) govern who can act but not why or whether they should. As agents gain autonomy, this becomes a systemic risk: authorized yet misaligned agents can act outside intended human norms. Every player in the $8.5B AI security market addresses what agents can do. None addresses what agents intend to do. None addresses what agents should do.
These five RFCs define the governance primitives for the missing layers.
Architecture
+-----------------------------------------+
| Human Authorities |
| (policy authors, reviewers, arbiters) |
+----+------------------+-----------------+
| |
v v
+========================+==================+=========================+
| TAMED AUTONOMY RFCs |
| |
| +------------------+ +-------------------+ |
| | TA-Intent |<------>| TA-Normative | |
| | | | | |
| | Intent | eval | Normative | |
| | declarations, |------->| constraints, | |
| | scope contracts, | result | soul vetoes, | |
| | amendments, |<-------| risk reclass., | |
| | composite intent | | context sources | |
| +--------+---------+ +---------+---------+ |
| | | |
| | compliance | clearance |
| | signals | + soul constraints |
| v v |
| +------------------+ +-------------------+ |
| | TA-Attestation |------->| TA-TrustProof | |
| | | | | |
| | Scope evaluation | feeds | ta_extension: | |
| | per action, |------->| intent_compliance | |
| | composite signal | | normative_clear. | |
| | detection, | | provenance_ref | |
| | swarm binding | +-------------------+ |
| +--------+---------+ |
| | |
| | correlation tags, |
| | sponsor principal |
| v |
| +------------------+ |
| | TA-Provenance | |
| | | |
| | Purpose chain | |
| | ledger, | |
| | delegation | |
| | authority, | |
| | scope | |
| | attenuation | |
| +------------------+ |
| |
+========================+============================================+
|
| extends / feeds into
v
+========================+============================================+
| KINETIC TRUST PROTOCOL (KTP) |
| |
| KTP-Core Trust computation: E_trust = E_base x (1 - R) |
| KTP-Identity Trajectory Chains, Sponsorship Bonds, Lineage |
| KTP-Enforce Enforcement pipeline: Sig -> Soul -> Tier -> A |
| KTP-Federation Trust Factor attenuation, zone agreements |
| KTP-Provenance Model provenance, Origin Ceremony |
| KTP-Emergency Circuit breakers, graceful degradation |
| KTP-Governance Recursive governance constraints |
| |
+=====================================================================+
|
| built on
v
+========================+============================================+
| EXISTING INFRASTRUCTURE |
| |
| OAuth 2.0 / OIDC API keys RBAC/ABAC MCP SPIFFE/SPIRE |
| |
+=====================================================================+
Data Flow
Agent wants to act | 1. Agent declares intent (TA-Intent) | | | v 2. Normative engine evaluates purpose (TA-Normative) | - Fetches context (HR, data classification, regulatory) | - Evaluates constraints (CEL predicates) | - Returns: approved / conditional / denied | - Generates: soul vetoes, risk reclassifications | 3. Intent bound as behavioral contract | - Scope entries mapped to action risk scores | - Trust proof issued with ta_extension (TA-TrustProof) | - Purpose chain verified (TA-Provenance) | 4. Agent acts — each action passes through enforcement pipeline: | a. Signature validation (KTP step 1) | b. TA contract + clearance check (TA-TrustProof step 1 ext.) | c. Soul veto: KTP behavioral OR TA normative (step 2) | d. Scope evaluation (TA-Attestation) | e. Tier gate (KTP step 3) | f. Physics check: A <= E_trust (KTP step 4) | 5. Each action recorded: | - Allowed: Trajectory Chain + ta_attestation | - Denied: Flight Recorder | - Composite signals streamed to Analysis Layer | 6. Trust proof refreshed with updated compliance_rate
The RFCs
TA-Intent — Intent Declaration Protocol
Type: TA-original (full specification)
Defines structured, machine-readable purpose statements that travel with every agent action and serve as enforceable behavioral contracts. An agent declares what it intends to do before acting; the declaration becomes a scope contract enforced at every action. Covers intent declaration format, scope entries with structured constraints, contract lifecycle (declared → evaluating → bound → amended → violated → expired → terminated → composite_suspended), scope amendment protocol, and composite intent reconstruction for multi-agent swarm detection.
The flagship primitive. No existing standard addresses this. The competitive analysis shows zero market entrants for general-purpose intent verification.
TA-Normative — Normative Constraint Protocol
Type: TA-original (full specification)
Defines the “should” layer — machine-enforceable rules that evaluate agent purpose against organizational policy, regulatory requirements, and ethical boundaries, independent of access control. Covers two constraint types: soul vetoes (binary S=1 denials based on context — e.g., departing employee + trade secrets) and action risk reclassifications (dynamic A score adjustments — e.g., patient safety lowers alert risk). Uses CEL (Common Expression Language) for deterministic predicate evaluation against a typed context schema. Includes dual-evaluation protocol for soul vetoes, continuous re-evaluation on context change, and escalation to human authority.
The normative gap. No vendor, framework, or standard addresses “should this agent do this given organizational context?”
TA-TrustProof — Trust Proof Extension
Type: KTP extension
Extends KTP Trust Proof Tokens with three fields: intent_compliance (active intent binding, compliance rate, contract status), normative_clearance (active constraints, soul vetoes, reclassifications, clearance level and expiry), and provenance_ref (link to purpose chain ledger). Defines how the enforcement pipeline is modified when ta_extension is present, including the step-1 contract/clearance check, combined soul veto (KTP behavioral + TA normative), clearance expiry validation, and fallback to KTP-only when ta_extension is absent.
TA-Attestation — Behavioral Attestation Extension
Type: KTP extension
Extends KTP Trajectory Chain entries with per-action scope evaluation results (scope_match, scope_distance), normative signals, and composite behavior detection signals. The TA-original contribution is composite behavior detection: data flow hashing, correlation tags, and a 5-criteria swarm session binding mechanism that detects coordinated multi-agent activity (common sponsor, data lineage chain, temporal proximity, resource domain overlap, destination escalation).
TA-Provenance — Provenance Extension
Type: KTP extension
Extends KTP Provenance with purpose-chain tracking — recording not just where an agent came from (model provenance) or what it has done (trajectory), but why it was created and what chain of delegated purposes authorized its existence. Defines a two-artifact model: a sealed ta_provenance_snapshot in the KTP Provenance Attestation (immutable after Origin Ceremony) and a mutable purpose chain ledger maintained by the Trust Oracle. Enforces strict scope attenuation, purpose coherence verification, and cascading scope narrowing.
Cross-RFC Dependencies
TA-Intent <-------> TA-Normative
| (bidirectional: |
| intent evaluated |
| by normative; |
| normative result |
| modifies binding) |
| |
| compliance | clearance + soul
| signals | constraints
v v
TA-Attestation -------> TA-TrustProof
| (scope eval ^ (intent compliance,
| results feed | normative clearance,
| compliance rate) | provenance ref)
| |
v |
TA-Provenance ----------+
(purpose chain
feeds intent
verification;
provenance_ref
in trust proof)
All five --> KTP-Core, KTP-Identity, KTP-Enforce,
KTP-Federation, KTP-Provenance,
KTP-Emergency, KTP-Governance
Status
These RFCs are v0.1 Preliminary/Experimental. They represent design targets, not shipping implementations. They have been through a 5-round adversarial review (Claude vs. Codex) with 20 issues identified and resolved.
The RFCs use RFC 2119 key words (MUST, SHOULD, MAY) and include JSON schemas, protocol flow diagrams, and worked examples from the scenario walkthroughs. They are structured for potential elevation to IETF/W3C standards-track.
The Kinetic Trust Protocol (KTP) provides the trust physics substrate these RFCs extend.
Leave a Reply