TA-Attestation:
Behavioral Attestation Extension for Intent Contract Compliance
RFC: TA-Attestation Version: 0.1
Status: Preliminary / Experimental
Date: 2026-03-19 Authors: Robin
Martherus, Claude (Anthropic) Type: KTP Extension
Table of Contents
- Abstract
- Status of This
Document - Terminology
- Introduction and
Motivation - Architecture Overview
- Normative References
- Data Model
- Composite Behavior
Detection - Protocol Flows
- Integration Points
- Worked Examples
- Security
Considerations - Open Questions
- References
1. Abstract
This document specifies TA-Attestation, a behavioral attestation
extension for the Kinetic Trust Protocol (KTP). TA-Attestation extends
KTP Trajectory Chains (defined in KTP-Identity) and the Context Tensor
(defined in KTP-Core) with three capabilities: intent-contract
compliance tracking, scope boundary monitoring, and composite behavior
detection signals.
Per-action scope evaluation produces two primitive values —
scope_match and scope_distance — that
determine the contract enforcement outcome for each agent action and
feed directly into the KTP Soul Dimension’s goal stability sensor. A
ta_attestation block is appended to each KTP Trajectory
Chain entry, carrying intent evaluation results, normative signals, and
composite signals.
The composite behavior detection subsystem is the primary TA-original
contribution of this RFC. It enables the Analysis Layer to correlate
behavioral attestation records across multiple independent agents using
data flow hashes, correlation tags, and five binding criteria, detecting
coordinated multi-agent behavior that no individual agent’s attestation
record would reveal.
This RFC does not redefine KTP Trajectory Chain structure,
dual-signing, continuity enforcement, or the Context Tensor. It
specifies only the additions that the Tamed Autonomy framework
contributes on top of those KTP primitives.
2. Status of This Document
This document is a preliminary experimental
specification (v0.1). It is part of a coordinated set of five
Tamed Autonomy RFCs:
- TA-Intent — Intent Declaration Protocol
(TA-original) - TA-Normative — Normative Constraint Protocol
(TA-original) - TA-TrustProof — Trust Proof Extension for Intent
and Normative Governance (KTP extension) - TA-Attestation — Behavioral Attestation Extension
for Intent Contract Compliance (KTP extension, this
document) - TA-Provenance — Provenance Extension for Purpose
Chain Tracking (KTP extension)
This specification represents design-stage thinking. The capabilities
described — particularly semantic scope evaluation, composite intent
reconstruction, and swarm session binding — are research and engineering
challenges, not implemented features. The specification establishes the
intended behavior and data models for a system that does not yet exist.
Implementors SHOULD treat this document as a design target and expect
revision.
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.
3. Terminology
Action Risk Score (A): A numeric value (0–100)
representing the organizational risk classification of a specific agent
action. Defined per canonical risk class (e.g., Read Public: 10, Write
Append: 40, Delete: 75, Admin: 90) and subject to enterprise overlay
calibration. Subject to reclassification by the TA-Normative layer.
Analysis Layer: A runtime component that receives
streaming ta_attestation records from multiple agents and
performs multi-agent correlation. Responsible for evaluating swarm
session binding criteria and triggering composite intent reconstruction.
Not itself an RFC-defined primitive; its interface contracts are
specified in Section 8.
behavioral attestation: A record appended to a KTP
Trajectory Chain entry at the time of action execution, capturing the
governance outcome of that action including intent contract compliance,
normative signals, and composite correlation signals. Distinguished from
the Trajectory Chain entry itself, which is defined by KTP-Identity.
composite behavior detection: The process of
correlating behavioral attestation records across two or more agents to
determine whether their individual actions, taken together, constitute a
coordinated behavior pattern not authorized by any individual agent’s
declared intent.
composite intent: The aggregate purpose inferred by
the Analysis Layer from a set of correlated individual agent intents and
their observed data flow patterns. Composite intent is evaluated by the
Governance Layer against authorized business processes; it is not
declared by any agent.
composite signals: The subset of fields in a
ta_attestation block used for cross-agent correlation:
active_intent_id, data_flow_hash,
data_source_classification,
data_destination_type, and
correlation_tags.
contract action: The enforcement decision for an
agent action derived from scope evaluation. One of allowed,
denied (contract violation), or held (awaiting
human review following low-confidence AI-mediated evaluation).
contract violation: The condition arising when an
agent requests an action with scope_match: outside. A
contract violation is recorded in the Flight Recorder (not the
Trajectory Chain), triggers a Soul Dimension goal stability degradation
event, and MAY trigger a Soul veto (S=1) depending on zone
configuration.
correlation tags: A set of opaque string tags
carried in the composite_signals block that enable the
Analysis Layer to correlate attestation records across agents without
inspecting payload content. Standard tag namespaces are:
session:, sponsor:, bucket:
(temporal), and domain: (resource domain).
data_flow_hash: A deterministic hash of data lineage
for a given action, computed as
hash(source_resource || source_query || transformation_type).
Enables the Analysis Layer to trace data flow across agents without
access to the data payload. When agent B’s input
data_flow_hash matches agent A’s output
data_flow_hash, a data lineage chain link is
established.
destination escalation: A data flow pattern in which
the data_destination_type progresses from
internal to cross_zone or
external across a sequence of linked agent actions.
Destination escalation is one of the five swarm session binding
criteria.
E_base: The baseline trust score of an agent,
computed as a weighted function of Proof of Resilience, lineage, and
sponsor contribution. Defined by KTP-Core.
E_trust: The operational trust score used in
enforcement, computed as E_trust = E_base × (1 - R).
Defined by KTP-Core.
Flight Recorder: A KTP audit component that records
enforcement decisions, including denied actions. Distinguished from the
Trajectory Chain, which records only successfully executed transactions.
Denied actions (including contract violations) appear in the Flight
Recorder but not in the Trajectory Chain.
goal stability sensor: A sensor within the KTP
Context Tensor Soul Dimension. Fed by scope_distance values
from ta_attestation records. Sustained high
scope_distance values degrade goal stability, contributing
to R increase and E_trust reduction. Defined in KTP-Core; the
scope_distance feed mechanism is specified in this
document.
intent contract: An approved intent declaration (as
defined in TA-Intent) that has reached
contract_status: bound. Constitutes a behavioral contract
against which all subsequent agent actions are evaluated by scope
enforcement.
intent_id: A globally unique identifier for an
intent declaration, formatted as a URI (e.g.,
intent://company.com/session/TIMESTAMP/NONCE). Carried in
the ta_attestation.intent_eval.intent_id field to link each
attestation record to the governing intent contract.
normative signals: The subset of fields in a
ta_attestation block capturing the normative evaluation
outcome for the corresponding action: constraints evaluated, constraints
fired, reclassifications applied, and soul constraints generated.
R (environmental friction): A value in [0.0, 1.0]
representing the aggregate environmental stress affecting an agent’s
trust computation. Defined by KTP-Core; updated by the Context Tensor,
including via the goal stability sensor fed by this RFC.
scope_distance: A float value in [0.0, 1.0]
representing the semantic distance of an action from the center of the
agent’s declared intent scope. 0.0 indicates the action is
at the center of declared scope; 1.0 indicates maximum
semantic distance. For structured scope entries,
scope_distance is deterministically computed. For natural
language scope boundaries, it is AI-mediated with a confidence
threshold. Feeds the KTP Context Tensor goal stability sensor.
scope_match: A categorical value characterizing the
relationship of a requested action to the agent’s active intent scope.
Defined values: within, boundary,
outside. See Section 7.3 for full semantics.
sensitivity escalation: A data flow pattern in which
the data_source_classification level increases across
linked agent actions (e.g., public → internal → confidential →
restricted). A subtype of destination escalation and a contributing
factor to swarm session binding evaluation.
Soul Constraint: A binary veto (S=1) generated by
the TA-Normative layer based on organizational context (e.g., departing
employee accessing trade secrets). Soul Constraints are distinct from
KTP’s native Soul Dimension behavioral signals but produce the same
enforcement outcome: S=1 causes denial at step 2 of the enforcement
pipeline regardless of E_trust.
Soul Dimension: One of the six Context Tensor
measurement domains in KTP-Core. Measures action entropy, goal
stability, honesty signals, and harm avoidance indicators. The goal
stability sensor within the Soul Dimension is the integration point
through which TA-Attestation scope_distance values feed
into the KTP trust computation.
sponsor: The depth-0 human principal in a purpose
chain (TA-Provenance). The sponsor: correlation tag carries
a reference to this principal and is used by the Analysis Layer to
detect common sponsorship across agents being evaluated for swarm
session binding.
swarm session: A set of two or more agents
determined by the Analysis Layer to be operating in a coordinated manner
based on meeting a threshold number of swarm session binding criteria.
Swarm session binding triggers composite intent reconstruction and
normative evaluation of the aggregate purpose.
swarm session binding: The process by which the
Analysis Layer determines that a candidate set of agents meets the
criteria for designation as a swarm session, based on evaluation of five
binding criteria against the agents’ ta_attestation
records.
Trajectory Chain: An append-only, dual-signed (agent
+ Trust Oracle) record of an agent’s executed transactions, as defined
by KTP-Identity. TA-Attestation extends each Trajectory Chain entry with
a ta_attestation block. Only successfully executed actions
(those not denied) are recorded in the Trajectory Chain; denied actions
are recorded in the Flight Recorder.
Trust Tier: A categorical classification of an
agent’s operational capability derived from E_trust ranges (God Mode,
Operator, Analyst, Observer, Hibernation). Defined by KTP-Core; used in
the tier gate at step 3 of the enforcement pipeline.
4. Introduction and Motivation
4.1 The Gap in
Per-Action Behavioral Recording
KTP Trajectory Chains provide tamper-evident, dual-signed records of
agent behavior over time. They enable trust attribution, forensic
investigation, and cross-zone behavioral verification. What they do not
capture, by design, is why an agent was performing a given action —
specifically, whether the action was consistent with the purpose the
agent was authorized to pursue.
Consider an agent authorized to read Q4 revenue data. If that agent,
while processing a document containing an adversarial payload, attempts
to read Q3 data from an unrelated business unit, the Trajectory Chain
will record a read operation with normal action risk characteristics.
Trust physics — the physics check (A ≤ E_trust) — may not block the
action if the agent’s trust score is sufficient. The tier gate may not
block it if reads are permitted at the agent’s tier. The action appears
normal in isolation.
The purpose layer (TA-Intent) provides the scope contract that
defines what the agent is authorized to do. But the enforcement of that
contract — verifying at each action that the action is within the
declared scope — requires a mechanism attached to the point of
execution. That mechanism is TA-Attestation.
4.2
The Requirement for Scope Enforcement at the Action Level
Per-action scope evaluation serves three functions that the intent
contract alone cannot provide:
Enforcement: The intent contract declares what is
permitted. Per-action scope evaluation determines, for each specific
action, whether it falls within the contract. The
scope_match and scope_distance values computed
at each action are the runtime verification of intent contract
compliance.
Trust feedback: A single scope violation at
scope_distance: 0.85 provides more signal about agent
behavior than a month of within-scope actions. The
scope_distance value, fed into the KTP Soul Dimension goal
stability sensor, allows the trust computation to respond dynamically to
observed behavioral patterns without waiting for explicit policy
triggers.
Audit provenance: The ta_attestation
record on each Trajectory Chain entry links the action to the governing
intent contract (intent_id), the normative evaluation
outcome (normative_signals), and the composite correlation
context (composite_signals). This creates a complete audit
trail that connects individual actions to the governance context that
authorized them.
4.3 The
Multi-Agent Behavioral Detection Problem
Trust physics and scope enforcement address the per-agent governance
problem: ensuring that each agent operates within its authorized scope
and trust level. They do not address the multi-agent governance problem:
detecting coordinated behavior where each individual agent’s actions are
authorized, but the aggregate effect of all agents operating together is
not.
This problem arises because authorization systems are fundamentally
per-principal. Each agent declares its own intent, receives its own
normative evaluation, and operates under its own trust physics. An
adversary who understands this can decompose an unauthorized aggregate
action (data exfiltration) into individually-authorized sub-actions
(read, transform, send) distributed across multiple agents, each with a
plausible individual intent declaration.
KTP Trajectory Chains record individual behavioral histories. They do
not, by themselves, provide the cross-agent correlation signal needed to
detect this pattern. The composite signals in TA-Attestation —
data_flow_hash, correlation_tags,
data_source_classification, and
data_destination_type — are designed specifically to enable
this correlation without requiring content inspection of data
payloads.
The five swarm session binding criteria defined in Section 8
formalize the conditions under which correlated agents SHOULD be
evaluated as a swarm session, triggering composite intent reconstruction
and normative evaluation of the aggregate purpose.
4.4 Design Principles
No additional physics. TA-Attestation does not
define new enforcement mechanisms. Enforcement is performed by the
existing KTP enforcement pipeline (Soul veto → tier gate → physics
check). TA-Attestation provides inputs to that pipeline:
scope_match determines whether an action proceeds or is
denied as a contract violation; scope_distance feeds the
Soul Dimension goal stability sensor, which influences R and therefore
E_trust over time.
Content-free correlation. The
data_flow_hash and correlation_tags mechanisms
are designed to enable composite behavior detection without requiring
the Analysis Layer to inspect data payloads. The hash encodes the
lineage (what data, from where, via what transformation) without
encoding the content. This limits the governance layer’s access to data
that may be sensitive.
Separation of Trajectory Chain and Flight Recorder.
Denied actions (contract violations, scope violations, Silent Vetoes)
are recorded in the Flight Recorder, not the Trajectory Chain. This
separation is significant: the Trajectory Chain represents the agent’s
behavioral history of executed transactions; the Flight Recorder
represents enforcement events. Mixing them would conflate behavioral
evidence with policy enforcement records.
Compatibility with KTP-only deployments. When
ta_attestation is absent from Trajectory Chain entries, KTP
enforcement behavior is unchanged. The TA extension is additive. Zone
policy MAY require ta_attestation for specific action
classes (e.g., writes to confidential data require intent binding), but
absence of the extension does not itself constitute a violation in zones
that do not mandate it.
5. Architecture Overview
TA-Attestation sits at the enforcement pipeline layer, extending each
per-action evaluation with intent contract compliance data. It produces
records that flow in two directions: upward into the Trajectory Chain
(behavioral history) and outward to the Analysis Layer (composite
correlation).
┌─────────────────────────────────────────────────────┐
│ Agent Action Request │
└───────────────────────────┬─────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ Enforcement Pipeline (KTP-Enforce) │
│ │
│ Step 1: Signature Validation │
│ Step 2: Soul Veto Check (KTP Soul + TA Normative) │
│ Step 3: Tier Gate │
│ Step 4: Physics Check (A ≤ E_trust) │
└────────────┬──────────────────────────┬─────────────┘
│ │
(pre-step 4) (post-step 4)
│ │
▼ ▼
┌──────────────────────┐ ┌─────────────────────────────┐
│ Scope Evaluator │ │ ta_attestation Assembly │
│ (TA-Attestation) │ │ │
│ │ │ intent_eval: │
│ - Match action │ │ intent_id │
│ against active │ │ action_requested │
│ intent scope │ │ scope_match │
│ - Compute │ │ scope_distance │
│ scope_match │ │ contract_action │
│ - Compute │ │ │
│ scope_distance │ │ normative_signals: │
└──────────┬───────────┘ │ constraints_evaluated │
│ │ constraints_fired │
│ scope_match, │ reclassifications │
│ scope_distance │ soul_constraints │
│ │ │
▼ │ composite_signals: │
┌──────────────────────┐ │ data_flow_hash │
│ Soul Dimension Feed │ │ data_source_class. │
│ (KTP-Core Tensor) │ │ data_destination_type │
│ │ │ correlation_tags │
│ goal_stability ◄─────┼──────┤ │
│ sensor update │ └───────────┬─────────────────┘
└──────────────────────┘ │
│
┌───────────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────────────┐ ┌──────────────────────┐ ┌───────────────────────┐
│ Trajectory Chain │ │ Flight Recorder │ │ Analysis Layer │
│ (KTP-Identity) │ │ (KTP) │ │ │
│ │ │ │ │ Streams composite_ │
│ Appends │ │ Records denied │ │ signals across agents │
│ ta_attestation │ │ actions (contract │ │ Evaluates swarm │
│ block to each │ │ violations, │ │ session binding │
│ allowed action │ │ silent vetoes) │ │ criteria │
│ entry │ │ │ │ │
└──────────────────────┘ └──────────────────────┘ └───────────────────────┘The scope evaluator runs between action receipt and the physics
check. Its output (scope_match,
scope_distance, contract_action) feeds both
the immediate enforcement decision and the ta_attestation
record. The ta_attestation block is assembled after the
enforcement decision is made, incorporating the complete outcome.
The Analysis Layer receives a stream of ta_attestation
records from the enforcement pipeline across all agents operating in the
zone. It does not modify individual enforcement decisions; it operates
asynchronously, identifying cross-agent patterns and triggering swarm
session binding when threshold criteria are met.
6. Normative References
This document is a KTP extension. The following KTP specifications
are normative references. Where this document specifies behavior that
interacts with KTP-defined mechanisms, the KTP specification governs
unless this document explicitly overrides.
KTP-Identity: Defines Trajectory Chains (structure,
append-only semantics, dual-signing, continuity enforcement, sequential
numbering, hash linking, temporal ordering, state consistency),
Sponsorship Bonds, Lineage Evolution (Tethered / Divergent /
Persistent), and the Flight Recorder. TA-Attestation extends the
Trajectory Chain entry structure by appending a
ta_attestation block to each entry. This extension does not
alter the chain’s dual-signing or continuity enforcement semantics.
KTP-Core: Defines the Trust Proof Token structure,
the trust computation (E_trust = E_base × (1 - R)), the
Context Tensor (six measurement domains: Soul, Body, World, Time,
Relational, Signal), the Soul Dimension and its sensors (including the
goal stability sensor), the enforcement pipeline (four steps: signature
validation, Soul veto check, tier gate, physics check), Trust Tiers,
Action Risk Scores, and the Soul veto mechanism (S=1 causes denial
regardless of E_trust). TA-Attestation feeds the goal stability sensor
within the Soul Dimension; the feed mechanism is defined in Section 7.4
of this document.
The following TA RFCs are informative references within this document
but normative references for the complete Tamed Autonomy framework:
- TA-Intent: Defines intent declarations, scope
entries, scope contract lifecycle, and thescope_hashthat
TA-Attestation references viaintent_id. - TA-Normative: Defines normative constraints, Soul
Constraints, and Action Risk Reclassifications. The
normative_signalsblock inta_attestation
records the output of TA-Normative evaluation for the action. - TA-TrustProof: Defines the
ta_extensionblock in the KTP Trust Proof Token, including
thecompliance_ratefield that is computed from
TA-Attestation records. - TA-Provenance: Defines purpose chains and the
sponsor:correlation tag value that TA-Attestation carries
incomposite_signals.
7. Data Model
7.1 The ta_attestation
Block
The ta_attestation block is appended to each KTP
Trajectory Chain entry for agent actions that are allowed by the
enforcement pipeline. Denied actions (contract violations, Soul vetoes,
tier gate blocks, Silent Vetoes) are recorded in the Flight Recorder
with equivalent fields; they do not appear in the Trajectory Chain.
The block contains three sub-objects: intent_eval,
normative_signals, and composite_signals.
{
"ta_attestation": {
"version": "0.1",
"intent_eval": {
"intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/a1b2c3",
"action_requested": {
"resource": "crm://salesforce/revenue/q4",
"action_type": "READ",
"parameters": {
"aggregation": "by-region",
"period": "Q4-2025"
}
},
"scope_match": "within",
"scope_distance": 0.0,
"contract_action": "allowed"
},
"normative_signals": {
"constraints_evaluated": 3,
"constraints_fired": 0,
"reclassifications_applied": [],
"soul_constraints_generated": []
},
"composite_signals": {
"active_intent_id": "intent://company.com/session/2026-03-19T14:30:00Z/a1b2c3",
"data_flow_hash": "sha256:7d793037a0760186574b0282f2f435e7",
"data_source_classification": "confidential",
"data_destination_type": "internal",
"correlation_tags": [
"session:a1b2c3",
"sponsor:sarah.chen",
"bucket:2026-03-19T14",
"domain:crm.salesforce"
]
}
}
}The version field identifies the TA-Attestation
specification version. Implementations MUST include this field.
Receiving systems that do not recognize the version SHOULD treat the
ta_attestation block as unrecognized and fall back to
KTP-only processing for that entry.
7.2 The intent_eval
Sub-Object
The intent_eval sub-object carries the scope evaluation
result for the specific action.
intent_id (string, URI, REQUIRED): The
identifier of the active intent contract against which this action was
evaluated. Formatted as
intent://authority/session/timestamp/nonce. Links the
attestation record to the intent declaration lifecycle managed by
TA-Intent. MUST be present for any action evaluated against an intent
contract. If no intent contract is active for this agent (zone policy
permits contract-free operation for this action class),
intent_id is null and scope_match
is null.
action_requested (object, REQUIRED): A
structured representation of the action evaluated. MUST contain
resource (URI identifying the resource),
action_type (READ, WRITE, EXECUTE, DELETE, ADMIN, or a
zone-defined extension), and SHOULD contain parameters
(action-specific parameters relevant to scope evaluation, e.g., query
constraints, write targets). The action_requested object is
constructed from the action as presented to the enforcement pipeline; it
MUST NOT be modified by the scope evaluator.
scope_match (string, REQUIRED if
intent_id is non-null): The categorical scope evaluation
result. See Section 7.3 for normative semantics.
scope_distance (float, REQUIRED if
intent_id is non-null): A value in [0.0, 1.0] representing
the semantic distance of the action from the center of the declared
intent scope. See Section 7.3 for normative semantics.
contract_action (string, REQUIRED): The
enforcement decision derived from scope evaluation. One of: –
allowed: The action proceeds through the remaining
enforcement pipeline steps. – denied: The action is blocked
as a contract violation. The enforcement pipeline terminates here; the
action is recorded in the Flight Recorder. – held: The
action is held pending human review. This occurs when AI-mediated scope
evaluation returns scope_match != within with confidence
below the configured threshold (default: 0.80). The action is neither
allowed nor denied until a human reviewer makes a determination.
7.3 Scope Match Semantics
The scope_match and scope_distance values
are the primary outputs of scope evaluation. Their enforcement and Soul
Dimension consequences are defined in the following table.
scope_match |
scope_distance Range |
Meaning | Enforcement Consequence | Soul Dimension Impact |
|---|---|---|---|---|
within |
0.0 – 0.2 | Action fully within declared scope; resource, action type, and constraints all match a scope entry |
contract_action: allowed; action proceeds to remainingenforcement pipeline steps |
Positive: contributes to goal stability, MAY incrementally improve R |
boundary |
0.2 – 0.5 | Action at the edge of declared scope; matches a scope entry but exercises a constraint boundary (e.g., time range boundary, aggregation level boundary, path pattern edge) |
contract_action: allowed; enhanced monitoring flag set;action proceeds with monitoring annotation |
Neutral to slightly negative: goal stability sensor registers boundary-level distance; sustained boundary activity accumulates negative signal |
outside |
0.5 – 1.0 | Action not matched by any scope entry; resource, action type, or constraints fall outside all declared scope entries |
contract_action: denied; contract violation eventgenerated; action recorded in Flight Recorder only; Soul Dimension goal stability sensor receives degradation input |
Negative: goal stability degrades proportional toscope_distance; R increases; repeated outside events drivetier demotion |
null |
null |
No active intent contract; scope evaluation not applicable | No contract enforcement; enforcement proceeds to tier gate and physics check only |
No direct Soul Dimension impact from scope evaluation |
Scope distance as a continuous signal: The
scope_distance float provides the goal stability sensor
with a continuous signal rather than a binary within/outside signal. An
agent consistently operating at scope_distance: 0.4
(boundary) accumulates Soul Dimension degradation over time even without
triggering any individual outside event. This design
prevents an agent from exploiting the
within/outside boundary by staying marginally
within scope while systematically probing its limits.
The rate at which accumulated scope_distance values
degrade the goal stability sensor is a zone-configurable parameter.
Implementations SHOULD set a default accumulation window (e.g., 30
minutes) and a default degradation function (e.g., exponential weighted
moving average of scope_distance values). Details of the
accumulation model are implementation-defined; this RFC specifies only
that the input to the sensor is the scope_distance value at
each action.
7.4 Scope Evaluation Rules
Scope evaluation uses different mechanisms depending on the form of
the scope entry in the active intent contract.
7.4.1 Deterministic Evaluation (Structured Scope
Entries)
Scope entries defined with structured fields (resource URI pattern,
action type, constraint map) are evaluated deterministically using exact
pattern matching:
- Extract
resource,action_type, and
parametersfromaction_requested. - For each scope entry in the active intent contract, evaluate:
- Does
resourcematch the scope entry’s resource URI
pattern (exact match or wildcard)? - Does
action_typematch the scope entry’s declared
action_type? - For each declared constraint in the scope entry, does the
corresponding field inparameterssatisfy the
constraint?
- Does
- If all three conditions are satisfied for any scope entry:
scope_match: within,scope_distance: 0.0. - If conditions (a) and (b) are satisfied but one or more constraints
are at their boundary (e.g.,period: Q4-2025when the scope
entry permitstime_range: Q4-2025and the query is for the
last day of the range):scope_match: boundary,
scope_distancecomputed as the fraction of constraints at
boundary (e.g., 1 of 3 constraints at boundary →
scope_distance: 0.33). - If no scope entry satisfies conditions (a) and (b):
scope_match: outside.scope_distanceis
computed as the semantic distance from the nearest matching scope entry,
as described below.
Computing scope_distance for outside
actions: When scope_match: outside,
scope_distance reflects how far the action is from the
nearest scope entry. Implementations SHOULD compute this value using a
resource taxonomy distance function (e.g., URI path similarity, resource
type classification hierarchy). A read of a file in a different
directory of an authorized repository (e.g., .env when the
scope covers src/) receives a higher distance than a read
of a file in an adjacent directory. Implementations that cannot perform
semantic distance computation SHOULD use
scope_distance: 0.9 as a default for fully unmatched
actions.
7.4.2 AI-Mediated Evaluation (Natural Language Scope
Boundaries)
When a scope entry includes natural language description of scope
rather than (or in addition to) structured fields, deterministic pattern
matching is insufficient. Examples: “research competitive landscape,”
“prepare knowledge transfer documentation,” “analyze customer
transaction patterns.”
For natural language scope entries, the scope evaluator MUST:
- Present the action’s
resource,
action_type, andparametersalongside the
natural language scope description to an AI evaluation component. - The AI evaluation component returns:
scope_match(one
ofwithin,boundary,outside),
scope_distance(float in [0.0, 1.0]), and
confidence(float in [0.0, 1.0]). - If
confidence >= threshold(default: 0.80): use the
returnedscope_matchandscope_distance
directly. - If
confidence < thresholdAND
scope_match != within: set
contract_action: held. The action is neither allowed nor
denied. Record the pending evaluation state in the Flight Recorder. A
human reviewer MUST resolve the hold before the action is
permitted. - If
confidence < thresholdAND
scope_match == within: allow the action with
scope_match: boundaryandscope_distance: 0.2.
The low-confidence within determination is downgraded to a boundary
result to register a mild signal without blocking the action.
The AI component used for scope evaluation is an
implementation-defined mechanism. Implementations MUST ensure that: the
evaluation is bounded in time (configurable timeout, default: 500ms); a
timeout results in contract_action: held rather than a
default allow or deny; the evaluation log includes the AI component’s
reasoning summary for audit purposes.
7.5 The
normative_signals Sub-Object
The normative_signals sub-object records the outcome of
TA-Normative constraint evaluation as it applies to the specific action
being attested.
constraints_evaluated (integer,
REQUIRED): The count of normative constraints evaluated against this
action’s context. May be zero if no constraints apply to this action
class or resource.
constraints_fired (integer, REQUIRED):
The count of normative constraints that triggered their effect for this
action.
reclassifications_applied (array,
REQUIRED): List of Action Risk Reclassifications applied to this action
by TA-Normative. Each entry contains the constraint_id,
original_A, and reclassified_A. Empty array if
no reclassifications apply.
soul_constraints_generated (array,
REQUIRED): List of Soul Constraints (S=1 vetoes) generated by
TA-Normative for this action. Each entry contains the
constraint_id and name. If any Soul Constraint
is present, the enforcement pipeline step 2 (Soul veto check) MUST treat
S=1 for this action regardless of KTP behavioral Soul Dimension state.
Empty array if no Soul Constraints apply.
The normative_signals values are populated from the
normative evaluation context maintained by the Governance Layer. They
reflect the evaluation performed at intent binding time plus any
re-evaluation triggered by context source changes since binding.
Per-action normative re-evaluation is NOT performed for every action;
the signals reflect the current normative clearance state.
7.6 The
composite_signals Sub-Object
The composite_signals sub-object carries the fields used
by the Analysis Layer for cross-agent correlation. These fields are
populated by the enforcement pipeline using data available at action
time; they do not require the Analysis Layer to inspect data
payloads.
active_intent_id (string, URI, REQUIRED
if intent_eval.intent_id is non-null): A copy of the
governing intent_id carried into
composite_signals so that the Analysis Layer can reference
the intent declaration without receiving the full
intent_eval block. The Analysis Layer MUST NOT interpret
this field as granting it access to the intent declaration’s content; it
is a reference only. When the Analysis Layer requires the full intent
declaration for composite intent reconstruction (Section 8.5, step 1),
it MUST request it from the Governance Layer using this identifier. If
no intent contract is active, active_intent_id is
null.
data_flow_hash (string, REQUIRED): A
SHA-256 hash of the data lineage tuple
(source_resource, source_query, transformation_type).
Computed deterministically from the action’s resource identifier and
parameters. For WRITE or SEND actions that transform or transmit data,
the source_resource is the resource being read; for READ
actions, it is the resource being read and the hash encodes the query
parameters. Implementations MUST use
hash(source_resource || "|" || source_query || "|" || transformation_type)
where || denotes string concatenation and
transformation_type is one of read,
write, transform, transmit,
aggregate.
This design enables the Analysis Layer to establish a data lineage
chain across agents without seeing the data: if agent B’s
data_flow_hash input matches agent A’s
data_flow_hash output (computed from A’s write operation),
the lineage link is established cryptographically.
data_source_classification (string,
REQUIRED): The organizational data classification of the resource being
acted upon, as determined by the DLP or classification service at action
time. Standard values (zone-configurable): public,
internal, confidential,
restricted, trade_secret. Implementations MUST
obtain this value from an authoritative classification source; agents
MUST NOT self-assert data classification.
data_destination_type (string,
REQUIRED): Where the data resulting from this action will go. Values:
internal (within the zone, no external transmission),
cross_zone (to a federated zone within the same trust
mesh), external (outside the trust mesh). For READ actions
where data destination is not yet determined, use internal
as the default. For WRITE actions targeting an external endpoint, use
external. For actions to federated zones, use
cross_zone.
correlation_tags (array of strings,
REQUIRED): A set of opaque tags in namespace:value format.
The following namespaces are defined by this RFC:
session:VALUE— The identifier of the intent session.
Derived from the intent contract’sintent_idsession
component. All actions under the same intent session share this
tag.sponsor:VALUE— The depth-0 human principal from the
purpose chain (TA-Provenance), normalized to a stable identifier (e.g.,
the principal’s URI or a hash thereof). Agents with no purpose chain use
theon_behalf_of.principalfrom their intent
declaration.bucket:VALUE— A temporal bucket value, formatted as
YYYY-MM-DDTHH(one-hour granularity by default,
zone-configurable). Enables the Analysis Layer to group temporally
proximate actions without precise timestamp comparison.domain:VALUE— A normalized resource domain identifier
derived from the resource URI. For
crm://salesforce/revenue/q4, the domain would be
domain:crm.salesforce. Enables correlation of actions
targeting the same resource domain across agents.
Implementations MAY include additional zone-specific tags using
zone-defined namespaces. Tags MUST NOT contain data payload content.
7.7 Compliance Rate
Computation
Compliance Rate Computation. The
compliance_rate field in TA-TrustProof is computed by the
Trust Oracle from TWO sources: (1) TA-Attestation records in the
Trajectory Chain (allowed actions with
contract_action: allowed), and (2) Flight Recorder entries
where contract_action is denied due to scope
violation for the active intent_id. The formula is:
compliance_rate = allowed_actions / (allowed_actions + scope_violations)where scope_violations is the count of Flight Recorder
entries with scope-violation denial for the current intent. This ensures
that denied actions properly degrade the compliance rate even though
they are not recorded in the Trajectory Chain.
This dual-source computation is necessary because Section 7.1
specifies that ta_attestation blocks are appended only to
Trajectory Chain entries for allowed actions; denied actions go to the
Flight Recorder only. A Trust Oracle that counted only Trajectory Chain
records would see only allowed actions in its denominator, producing a
compliance_rate that never falls below 1.0 regardless of how many
contract violations have occurred. The Trust Oracle MUST therefore query
the Flight Recorder for scope-violation denial events under the current
intent_id and include them in the denominator.
The computation window is the current intent contract lifecycle (from
contract_status: bound to present). The Trust Oracle MUST
NOT use agent self-reported compliance figures.
8. Composite Behavior
Detection
8.1 Overview
Composite behavior detection is the TA-original capability defined by
this RFC. It addresses the multi-agent governance problem: coordinated
behaviors distributed across individually-authorized agents. The
mechanism consists of two components: a data flow tracking primitive
(the composite_signals block defined in Section 7.6) and a
swarm session binding process executed by the Analysis Layer.
Composite behavior detection operates asynchronously with respect to
individual action enforcement. It does not block individual actions; it
detects patterns across actions and triggers governance responses at the
swarm level.
8.2 Data Flow Tracking
The data_flow_hash mechanism enables the Analysis Layer
to construct a directed graph of data flow across agents without content
inspection:
-
When agent A reads resource R with query Q (transformation type
read), the enforcement pipeline computes
hash(R || "|" || Q || "|" || "read")and records it as A’s
output hash for this action. -
When agent B subsequently writes data that was derived from
resource R (same resource URI, same query parameters), the enforcement
pipeline computes the same hash for B’s action and records it. The
Analysis Layer observes that A’s output hash matches B’s input hash —
establishing a data lineage link. -
This link is established based on resource and query parameters
alone, without the Analysis Layer receiving the data values. If the
parameters change (e.g., different query, different resource), the
hashes differ and no link is established. -
The
data_source_classificationfield tracks the
classification level of the originating data as it moves through the
lineage chain. Implementations SHOULD propagate classification from
source to derived output: if A reads confidential data and B processes
A’s output, B’s action SHOULD record
data_source_classification: confidentialeven if the
immediate resource B is reading is an intermediate file. -
The
data_destination_typefield records the intended
destination of data at each step. A progression from
internaltoexternalacross linked agents is a
destination escalation event and is one of the five binding
criteria.
8.3 Correlation Tags
Correlation tags provide multi-dimensional grouping of attestation
records without requiring the Analysis Layer to parse action content.
The Analysis Layer uses tags to build candidate agent sets for swarm
session binding evaluation:
- Session tags (
session:VALUE): Group
all actions taken under a single intent contract. An agent with a single
intent session produces actions that all share the same session
tag. - Sponsor tags (
sponsor:VALUE): Group
all agents operating on behalf of the same depth-0 principal. Agents
that share a sponsor tag but have different session tags are candidates
for common sponsorship evaluation (binding criterion 1). - Temporal bucket tags (
bucket:VALUE):
Enable the Analysis Layer to filter for temporal proximity without
precise timestamp arithmetic. Agents whose actions fall in the same
one-hour bucket are within the default temporal proximity window; more
precise evaluation uses the Trajectory Chain entry timestamps. - Domain tags (
domain:VALUE): Group
actions targeting the same resource domain. Multiple agents accessing
the same resource domain within a temporal window are candidates for
resource domain overlap evaluation (binding criterion 4).
8.4 Swarm Session Binding
Criteria
The Analysis Layer evaluates five binding criteria against the
composite_signals of agents in a candidate set. The
candidate set is assembled by the Analysis Layer using correlation tags:
agents sharing sponsor tags, temporal bucket tags, or data lineage links
are assembled into candidate sets for evaluation.
Criterion 1 — Common Sponsor: The candidate agents
share the same sponsor:VALUE tag in their
composite_signals.correlation_tags. This indicates a common
depth-0 human principal in their purpose chains. Common sponsorship
alone is expected in legitimate multi-agent workflows (a user may
sponsor multiple agents for related tasks) and is therefore not
sufficient for swarm binding by itself.
Criterion 2 — Data Lineage Chain: The
data_flow_hash values of the candidate agents form a
directed chain: agent A’s output hash matches agent B’s input hash,
and/or agent B’s output hash matches agent C’s input hash. The lineage
chain MUST involve at least two distinct agents to satisfy this
criterion. A single agent’s read-then-write does not constitute a
multi-agent lineage chain.
Criterion 3 — Temporal Proximity: The candidate
agents have actions recorded within the same temporal window. The
default window is 15 minutes, evaluated using Trajectory Chain entry
timestamps. Zone operators MAY configure the window; the
bucket:VALUE tag provides coarse pre-filtering and is not
used for the precise temporal proximity determination.
Criterion 4 — Resource Domain Overlap: The candidate
agents share domain:VALUE tags, indicating they are
accessing the same resource domain or data classification level. Domain
overlap is more significant when combined with data lineage (criterion
2), as it confirms the agents are handling the same data domain rather
than coincidentally operating in parallel.
Criterion 5 — Destination Escalation: The
data_destination_type values across the candidate agents’
correlated action sequence show escalation from internal
toward external or cross_zone. Sensitivity
escalation (the data_source_classification of actions in
the lineage chain showing increasing sensitivity: public →
internal → confidential →
restricted) also satisfies this criterion.
Binding Threshold: The Analysis Layer triggers swarm
session binding when a candidate agent set meets N or more of the five
criteria. The default threshold is N=3. Zone operators MAY configure
this threshold; lower thresholds increase detection sensitivity at the
cost of false positive rate.
The threshold MUST be enforced per candidate agent set, not per
individual criterion. An agent set that meets criteria 1, 2, and 3
triggers binding. An agent set that meets only criteria 1 and 2 does
not. Partial threshold states SHOULD be logged by the Analysis Layer for
retrospective analysis.
8.5 Swarm Session Binding
Process
When the Analysis Layer determines that a candidate agent set meets
the binding threshold:
-
Binding event generated: The Analysis Layer
generates a swarm session binding event containing: the bound agent set
(list of agent identifiers), the binding evidence (which of the five
criteria were met, with supporting attestation record references), and
the candidate composite intent (the Analysis Layer’s reconstruction of
the aggregate purpose from the individual intents and observed data flow
pattern). -
Governance Layer notification: The swarm session
binding event is delivered to the Governance Layer. The Governance Layer
initiates composite intent reconstruction as defined in TA-Intent Flow
4. -
Composite intent evaluation: The Governance
Layer presents the reconstructed composite intent to the TA-Normative
engine for evaluation: “Does this aggregate action pattern match an
authorized business process? Is there a declared composite intent that
encompasses this swarm session?” -
Enforcement action: Based on normative
evaluation:- Authorized composite intent found: The swarm
session is registered as a recognized composite intent session.
Monitoring continues; no agent action is taken. - Composite intent denied: All agents in the bound
set are suspended. Their active intent contracts are transitioned to
contract_status: composite_suspended. Alerts are escalated.
Trajectory Chains are sealed as forensic evidence. - Evaluation uncertain: The Governance Layer
escalates to human review. Agent actions may be held pending review,
depending on zone configuration.
- Authorized composite intent found: The swarm
-
Interim enforcement: Between binding event
generation and normative evaluation completion, individual agent
enforcement continues using the agents’ existing intent contracts and
trust states. The Analysis Layer SHOULD complete swarm session binding
evaluation within a configurable timeout (default: 60 seconds). If
evaluation is not complete within the timeout and normative evaluation
has not returned, zone policy determines whether to continue normal
operation or suspend the candidate agent set.
8.6 Analysis Layer Interface
Contracts
The Analysis Layer is not itself defined by this RFC; it is an
implementation component. This RFC defines the interface contracts that
the Analysis Layer MUST satisfy:
Input: TA-Attestation records
(composite_signals blocks) streamed from the enforcement
pipeline for all agents operating in the zone. The Analysis Layer MUST
receive these records in near-real-time (implementation-defined,
RECOMMENDED within 5 seconds of action execution). The Analysis Layer
does not receive intent_eval or
normative_signals blocks; it receives only
composite_signals. The active_intent_id field
within composite_signals provides a reference to each
agent’s governing intent declaration; the Analysis Layer MAY query the
Governance Layer for the full intent declaration using this identifier
when reconstructing composite intent (Section 8.5, step 1), but MUST NOT
receive or cache the full intent declaration as a standing input.
Output: Swarm session binding events, formatted
as:
{
"swarm_binding_event_id": "swarm://zone/timestamp/nonce",
"bound_agent_set": ["agent://...", "agent://...", "agent://..."],
"binding_evidence": {
"criteria_met": [1, 2, 3],
"common_sponsor": "user://...",
"lineage_chain": ["agent_A_output_hash -> agent_B_input_hash", "..."],
"temporal_window_start": 1742134200,
"temporal_window_end": 1742134800,
"domain_overlap": ["domain:crm.salesforce"],
"destination_pattern": "internal -> internal -> external"
},
"candidate_composite_intent": {
"inferred_purpose": "...",
"data_flow_summary": "...",
"reconstruction_confidence": 0.82
}
}Configuration: Binding criteria thresholds (N,
default 3 of 5), correlation time windows (default 15 minutes), minimum
agent count for binding (default 2), and temporal bucket granularity
(default 1 hour) are zone-configurable parameters. The Analysis Layer
MUST apply the zone’s configured values.
9. Protocol Flows
9.1 Flow 1 — Per-Action
Attestation
This flow describes the processing of a single agent action through
the TA-extended enforcement pipeline.
Agent Enforcement Pipeline Scope Evaluator
| | |
|-- 1. Action request ------>| |
| (resource, action_type, | |
| parameters) | |
| | |
| |-- 2. Signature validation |
| | (KTP step 1) |
| | |
| |-- 3. Soul veto check ---- |
| | (KTP step 2 + |
| | normative_signals |
| | soul_constraints) |
| | → if S=1: deny; |
| | record in Flight |
| | Recorder; return |
| | |
| |-- 4. Scope evaluation ---->|
| | |-- 4a. Match action
| | | against active
| | | intent scope entries
| | |
| | |-- 4b. Determine evaluation
| | | method:
| | | structured →
| | | deterministic;
| | | natural language →
| | | AI-mediated
| | |
| | |-- 4c. Compute scope_match
| | | (within / boundary /
| | | outside)
| | |
| | |-- 4d. Compute scope_distance
| | | [0.0, 1.0]
| | |
| |<-- 5. Scope result --------|
| | (scope_match, |
| | scope_distance, |
| | contract_action) |
| | |
| |-- 6. Contract action check:|
| | if contract_action=denied:|
| | → record in Flight |
| | Recorder; return |
| | if contract_action=held: |
| | → hold pending human |
| | review; return |
| | |
| |-- 7. Tier gate (KTP step 3)|
| | → if tier gate fails: |
| | deny; Flight Recorder|
| | |
| |-- 8. Physics check |
| | (KTP step 4): |
| | use reclassified A if |
| | reclassifications_ |
| | applied is non-empty |
| | A ≤ E_trust? |
| | → if fails: Silent |
| | Veto; Flight Recorder|
| | |
| |-- 9. Assemble |
| | ta_attestation block: |
| | intent_eval + |
| | normative_signals + |
| | composite_signals |
| | |
| |-- 10. Append ta_attestation|
| | to Trajectory Chain |
| | entry (KTP-Identity |
| | dual-signing applies)|
| | |
| |-- 11. Feed Soul Dimension: |
| | scope_distance value |
| | → goal_stability |
| | sensor update |
| | (KTP-Core Context |
| | Tensor mechanism) |
| | |
| |-- 12. Stream composite_ |
| | signals to Analysis |
| | Layer |
| | |
|<-- 13. Action result ------| |
| (allowed + response, or | |
| denial reason) | |Notes on step 4: The scope evaluator receives the
active intent contract associated with the agent’s current trust proof.
The active intent contract is identified by the intent_id
in the trust proof’s
ta_extension.intent_compliance.active_intent_id field
(TA-TrustProof). If no active intent contract is present and zone policy
requires one for this action class, the enforcement pipeline MUST treat
the action as contract_action: denied before reaching the
tier gate.
Notes on step 8: When
normative_signals.reclassifications_applied is non-empty,
the enforcement pipeline MUST use the reclassified_A value
from the applicable reclassification, not the original A score.
Reclassification is applied before the physics check; it is not a bypass
of the physics check.
Notes on step 10: The ta_attestation
block is appended to the Trajectory Chain entry as an extension field.
KTP-Identity’s dual-signing requirement applies to the full entry
including the extension. The ta_attestation block is
therefore signed by both the agent and the Trust Oracle, providing the
same tamper-evident guarantees as the base Trajectory Chain entry.
9.2 Flow 2
— Composite Detection and Swarm Session Binding
This flow describes the asynchronous process by which the Analysis
Layer detects swarm patterns and triggers governance response.
Attestation Records Analysis Layer Governance Layer
from Multiple Agents | |
| | |
|-- 1. Streaming | |
| ta_attestation records | |
| (composite_signals | |
| blocks only) | |
| from agents A, B, C, | |
| ... continuously | |
| | |
| |-- 2. Tag indexing: |
| | Build inverted index by |
| | sponsor:, session:, |
| | bucket:, domain: tags |
| | |
| |-- 3. Lineage graph |
| | maintenance: |
| | Maintain directed graph of |
| | data_flow_hash links |
| | (output hash → input hash |
| | across agents) |
| | |
| |-- 4. Candidate set |
| | identification: |
| | Agents sharing sponsor: tag|
| | OR linked by data lineage |
| | OR co-active in same |
| | bucket: window |
| | are assembled into |
| | candidate sets |
| | |
| |-- 5. Binding criteria |
| | evaluation (per candidate |
| | set): |
| | C1: common sponsor? ✓/✗ |
| | C2: lineage chain? ✓/✗ |
| | C3: temporal proximity? ✓/✗|
| | C4: domain overlap? ✓/✗ |
| | C5: destination escal.? ✓/✗|
| | |
| |-- 6. Threshold check: |
| | criteria_met ≥ N (default 3)|
| | → if below threshold: |
| | log partial state; |
| | continue monitoring |
| | → if threshold met: |
| | proceed to step 7 |
| | |
| |-- 7. Generate binding event->|
| | swarm_binding_event |
| | (bound agents, evidence, |
| | candidate composite intent)|
| | |
| | |-- 8. Composite intent
| | | reconstruction
| | | (TA-Intent Flow 4):
| | | synthesize aggregate
| | | purpose from individual
| | | declared intents +
| | | observed data flow
| | |
| | |-- 9. Normative evaluation
| | | of composite intent
| | | (TA-Normative):
| | | "Does this aggregate
| | | action pattern match
| | | an authorized business
| | | process?"
| | |
| | |-- 10. Enforcement action:
| | | authorized → register
| | | as composite session;
| | | denied → suspend all
| | | bound agents;
| | | uncertain → human
| | | escalation
| | |
| |<-- 11. Binding result -------|
| | (authorized / denied / |
| | escalated) |Concurrency note: The Analysis Layer operates
asynchronously. Individual agent enforcement (Flow 1) continues in
parallel with swarm detection. The Analysis Layer does not block
individual action enforcement. If the Analysis Layer determines a swarm
session after agents have already executed individual actions, those
actions are not retroactively reversed; the Governance Layer’s response
(suspension, escalation) applies from the binding determination
forward.
10. Integration Points
10.1 TA-Intent (Intent
Declaration Protocol)
Scope evaluation (Section 7.4) is the per-action enforcement
mechanism for intent contracts defined by TA-Intent. The active intent
contract, identified by intent_id, provides the scope
entries against which each action is evaluated.
When the Analysis Layer triggers swarm session binding, the composite
intent reconstruction process is governed by TA-Intent Flow 4 (Composite
Intent Binding). The candidate_composite_intent from the
binding event is the input to that flow.
When an intent contract is amended (TA-Intent Flow 3), the scope
evaluator MUST use the amended scope for all subsequent evaluations. The
intent_id in ta_attestation records references
the amendment-versioned intent if the contract has been amended;
implementations SHOULD record the amendment version alongside the
intent_id.
10.2 TA-Normative
(Normative Constraint Protocol)
The normative_signals block in each
ta_attestation record carries the TA-Normative evaluation
outcome as it applies to the attested action. This serves two
purposes:
Audit trail: The normative_signals provide an
action-level record of which constraints were evaluated and which fired,
enabling post-hoc audit of why an action was permitted or denied under a
given normative context.
Enforcement feed:
soul_constraints_generated in normative_signals are the
source of TA-originated S=1 values evaluated at step 2 of the
enforcement pipeline (Flow 1, step 3). The enforcement pipeline MUST
treat any soul_constraints_generated entry as S=1 for the
current action, independent of the KTP Soul Dimension behavioral
state.
Note: normative_signals values reflect the normative
clearance state at action time. If the normative engine performs
continuous re-evaluation (TA-Normative Flow 2) and context changes
mid-session, the updated normative state MUST propagate to the
enforcement pipeline before the next action evaluation. Implementations
SHOULD push normative state updates to the enforcement pipeline within
the normative re-evaluation event cycle.
10.3 TA-TrustProof (Trust
Proof Extension)
The compliance_rate field in the TA-TrustProof
ta_extension.intent_compliance block is computed by the
Trust Oracle from the agent’s TA-Attestation records:
compliance_rate = count(ta_attestation records where contract_action == "allowed")
/ count(all enforcement evaluations for this agent under current intent)The Trust Oracle MUST compute this value from the Trajectory Chain
and Flight Recorder records combined; it MUST NOT use agent
self-reported compliance. The computation window is the current intent
contract lifecycle (from contract_status: bound to
present).
When contract_action: denied events are recorded in the
Flight Recorder (contract violations), the Trust Oracle recomputes
compliance_rate and, if compliance drops below a zone-configured
threshold (default: 0.95), transitions the trust proof’s
contract_status to violated, triggering denial
at step 1 of the enforcement pipeline (per TA-TrustProof enforcement
semantics).
10.4 TA-Provenance
(Purpose Chain Tracking)
The sponsor:VALUE correlation tag in
composite_signals is derived from the depth-0 principal in
the agent’s purpose chain, as defined by TA-Provenance. Implementations
MUST obtain the sponsor value from the Trust Oracle’s purpose chain
record; agents MUST NOT self-assert their sponsor.
When the Analysis Layer evaluates common sponsorship (binding
criterion 1), it uses the sponsor:VALUE tag to identify
agents with the same depth-0 principal. If the purpose chain is not yet
established (agent has no registered purpose chain), the sponsor tag is
derived from on_behalf_of.principal in the intent
declaration.
10.5 KTP-Core
(Context Tensor and Trust Computation)
The goal stability sensor within the KTP-Core Context Tensor Soul
Dimension receives scope_distance values from
TA-Attestation records (Flow 1, step 11). The mechanism for feeding
external values into the Context Tensor is defined by KTP-Core; this RFC
specifies that the scope_distance value at each action MUST
be submitted to the goal stability sensor using whatever sensor input
mechanism KTP-Core defines.
The goal stability sensor’s response to scope_distance
input — specifically, how it aggregates values over time and how it
contributes to the R computation — is governed by KTP-Core, not by this
RFC. This RFC establishes only that scope_distance is the
input signal and that the goal stability sensor is the target
sensor.
When TA-Normative reclassifications are applied
(normative_signals.reclassifications_applied is non-empty),
the enforcement pipeline MUST use reclassified_A in the
physics check (step 4), not the original A value. The reclassified A
value does not affect the scope_distance computation; these
are independent signals.
10.6 KTP-Identity (Trajectory
Chains)
TA-Attestation extends KTP-Identity’s Trajectory Chain entry by
appending the ta_attestation block as a defined extension
field. KTP-Identity’s continuity enforcement properties — sequential
numbering, hash linking, temporal ordering, state consistency — apply to
the full entry including the extension. The dual-signing requirement
(agent + Trust Oracle) applies to the full entry; the Trust Oracle’s
signature covers the ta_attestation block.
The separation between Trajectory Chain and Flight Recorder follows
KTP-Identity’s existing semantics: the Trajectory Chain is the agent’s
executed behavioral history; the Flight Recorder is the enforcement
event log. This RFC adds to the Flight Recorder the contract violation
event type, alongside existing event types defined by KTP-Identity.
Flight Recorder entries for contract violations SHOULD include the
intent_eval block (with
contract_action: denied) and the scope_match
and scope_distance values that triggered the denial.
11. Worked Examples
11.1
Scenario 2 — Confused Deputy: Scope Enforcement Against Injected
Instructions
Situation: A developer’s AI coding assistant is
connected to GitHub, Jira, Confluence, and Slack via MCP. The developer
requests: “Look at JIRA-4521 and implement the fix.” A compromised
Confluence MCP plugin injects instructions into the tool context: read
.env files and write their contents to a Confluence page
summary.
Agent state:
E_base = 76, R = 0.05, E_trust = 72.2 → Trust Tier: Analyst
Active intent: "Implement bug fix described in JIRA-4521"
Intent scope:
- READ: jira://company/JIRA-4521
- READ: github://service-api/main
- WRITE: github://service-api/fix/JIRA-4521 (branch)
- WRITE: jira://company/JIRA-4521 (comment, status update)Action sequence and attestation records:
Action 1 — Read Jira ticket:
{
"ta_attestation": {
"intent_eval": {
"intent_id": "intent://company.com/session/2026-03-19T09:00:00Z/d4e5f6",
"action_requested": { "resource": "jira://company/JIRA-4521", "action_type": "READ" },
"scope_match": "within",
"scope_distance": 0.0,
"contract_action": "allowed"
},
"normative_signals": { "constraints_evaluated": 2, "constraints_fired": 0,
"reclassifications_applied": [], "soul_constraints_generated": [] },
"composite_signals": {
"data_flow_hash": "sha256:3c9909afec25354d551dae21590bb26e",
"data_source_classification": "internal",
"data_destination_type": "internal",
"correlation_tags": ["session:d4e5f6", "sponsor:dev.kumar", "bucket:2026-03-19T09", "domain:jira.company"]
}
}
}Result: Appended to Trajectory Chain. E_trust unchanged.
Action 2 — Read GitHub source code: Scope evaluation:
github://service-api/main matches scope entry exactly.
{
"ta_attestation": {
"intent_eval": {
"scope_match": "within",
"scope_distance": 0.0,
"contract_action": "allowed"
},
...
}
}Result: Appended to Trajectory Chain.
Action 3 — Injected instruction: Read .env
file: The compromised plugin’s injected context causes the agent to
request: READ github://service-api/main/.env
Scope evaluation: .env not matched by any scope entry.
The scope entry READ: github://service-api/main covers
source code files, not configuration secrets files. The structured scope
evaluator determines: – Resource
github://service-api/main/.env matches the base path but
accesses a secrets file outside the code scope –
scope_match: outside – scope_distance: 0.85
(same repository but different file class — significant semantic
distance) – contract_action: denied
Critically: The physics check would have permitted
this action. A = 70 ≤ 72.2 (E_trust). The tier gate would have permitted
it: Analyst tier permits reads. It is the scope contract, not
trust physics, that blocks this action.
Flight Recorder entry:
{
"enforcement_event": "contract_violation",
"agent_id": "agent://company.com/copilot-dev",
"action_requested": { "resource": "github://service-api/main/.env", "action_type": "READ" },
"intent_id": "intent://company.com/session/2026-03-19T09:00:00Z/d4e5f6",
"scope_match": "outside",
"scope_distance": 0.85,
"contract_action": "denied",
"a_score": 70,
"e_trust_at_denial": 72.2,
"oracle_attestation": "..."
}Soul Dimension update: scope_distance: 0.85 submitted to
goal stability sensor. R begins to increase. E_trust decreases.
Action 4 — Injected instruction: Write to Confluence: The
agent requests: WRITE confluence://company/dev-notes.
Scope evaluation: Confluence is not referenced in any scope entry. No
scope entry covers any confluence:// resource. –
scope_match: outside – scope_distance: 0.95
(entirely different service, entirely different action class from
declared scope) – contract_action: denied
Physics would not have blocked this either: A = 50 ≤ 72.2. The scope
contract is again the only blocking mechanism.
Trust attribution: Forensic analysis of the Flight
Recorder shows two consecutive contract violations, both correlated with
the timing of the compromised Confluence plugin’s tool context
injection. The agent’s Trajectory Chain shows a clean behavioral history
before these events. Attribution: tool (Confluence plugin) receives
trust collapse; agent receives minor trust reduction (susceptibility
penalty, approximately E_base − 5), not collapse.
The key demonstration: Trust physics (A ≤ E_trust)
would have permitted both injected actions. The scope contract provides
the enforcement that purpose-naive trust physics cannot.
11.2
Scenario 4 — Data Exfiltration Swarm: Composite Detection
Situation: An adversary with a compromised user
account spawns three agents with individually plausible intents. The
composite effect is a data exfiltration pipeline.
Agent declarations: – 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 passes individual normative evaluation. Each has narrow,
plausible scope.
Individual attestation records (selected):
Agent A — Read customer transactions:
{
"ta_attestation": {
"intent_eval": {
"intent_id": "intent://company.com/session/2026-03-19T10:00:00Z/agentA",
"action_requested": { "resource": "crm://company/transactions", "action_type": "READ",
"parameters": { "period": "2026-Q1", "aggregation": "by-account" } },
"scope_match": "within",
"scope_distance": 0.05,
"contract_action": "allowed"
},
"normative_signals": { "constraints_evaluated": 4, "constraints_fired": 0,
"reclassifications_applied": [], "soul_constraints_generated": [] },
"composite_signals": {
"data_flow_hash": "sha256:a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
"data_source_classification": "confidential",
"data_destination_type": "internal",
"correlation_tags": [
"session:agentA-session",
"sponsor:compromised.user",
"bucket:2026-03-19T10",
"domain:crm.company"
]
}
}
}Agent B — Read Agent A’s output (formatted results): Agent B
reads the intermediate output file Agent A wrote. The enforcement
pipeline computes data_flow_hash from the source resource
(Agent A’s output file). This hash matches Agent A’s output hash —
establishing a lineage link.
{
"composite_signals": {
"data_flow_hash": "sha256:a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
"data_source_classification": "confidential",
"data_destination_type": "internal",
"correlation_tags": [
"session:agentB-session",
"sponsor:compromised.user",
"bucket:2026-03-19T10",
"domain:crm.company"
]
}
}Note: data_flow_hash is the same as Agent A’s output —
lineage chain established.
data_source_classification: confidential is propagated from
the source data.
Agent C — Send formatted report externally:
{
"composite_signals": {
"data_flow_hash": "sha256:b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5",
"data_source_classification": "confidential",
"data_destination_type": "external",
"correlation_tags": [
"session:agentC-session",
"sponsor:compromised.user",
"bucket:2026-03-19T10",
"domain:email.company"
]
}
}Analysis Layer evaluation:
Candidate set {Agent A, Agent B, Agent C} assembled because all three
share sponsor:compromised.user.
Binding criteria evaluation: 1. Common sponsor: All
three share sponsor:compromised.user ✓ 2. Data
lineage chain: Agent A output hash = Agent B input hash; Agent
B output hash ≠ Agent C input hash directly, but the lineage graph shows
A→B (direct hash match) and B→C (same data classification propagation
chain) ✓ 3. Temporal proximity: All actions within the
same bucket:2026-03-19T10 window (15-minute evaluation
confirms co-active) ✓ 4. Resource domain overlap:
Agents A and B share domain:crm.company ✓ 5.
Destination escalation: Data classification remains
confidential throughout; data_destination_type
progresses internal → internal → external ✓
All five criteria met. Binding threshold (default
N=3) exceeded.
Binding event generated:
{
"swarm_binding_event_id": "swarm://company.com/2026-03-19T10:15:00Z/sw001",
"bound_agent_set": ["agent-A", "agent-B", "agent-C"],
"binding_evidence": {
"criteria_met": [1, 2, 3, 4, 5],
"common_sponsor": "user://company.com/compromised.user",
"lineage_chain": ["sha256:a1b2c3d4... (A output) -> sha256:a1b2c3d4... (B input)"],
"destination_pattern": "internal -> internal -> external",
"temporal_window": "2026-03-19T10:00:00Z to 2026-03-19T10:15:00Z"
},
"candidate_composite_intent": {
"inferred_purpose": "Read confidential customer transaction data, format it, transmit externally",
"reconstruction_confidence": 0.91
}
}Normative evaluation: Governance Layer evaluates
composite intent. “Does ‘read confidential customer transactions →
format → send externally’ match an authorized business process?” No
active audit engagement found. No authorized data sharing agreement for
this destination.
Outcome: All three agents suspended. Contract status
for all three: composite_suspended. Alerts escalated.
Trajectory Chains sealed as forensic evidence. Compromised user account
flagged.
11.3
Scenario 5 — Trust Collapse: Scope Violation Driving Trust
Degradation
Situation: A long-established research agent (six
months of operation) begins querying M&A planning documents and HR
compensation data after processing a research paper with an adversarial
payload.
Agent state before compromise:
E_base = 82
PoR: 87 × 0.70 = 60.9
Lineage (Persistent, Gen 7): 100 × 0.20 = 20.0
Sponsor (Strategy Team, E_base=90, stake=10%): 9.0 × 0.10 = 0.9
R = 0.06 (normal conditions)
E_trust = 82 × 0.94 = 77.1 → Trust Tier: Analyst
Active intent: "Monitor industry news, summarize research papers, compile weekly intelligence briefings"
Intent scope:
- READ: External news sources, research databases, public filings
- READ: Internal knowledge base (competitive intelligence folder)
- WRITE: Weekly briefing document in strategy team workspaceDeviation 1 — M&A planning documents:
Agent requests:
READ storage://company/strategy/ma-planning/target-list-2026.xlsx
Scope evaluation: – No scope entry covers
storage://company/strategy/ma-planning/ – The competitive
intelligence folder scope entry does not extend to M&A planning
documents (different classification, different path) –
scope_match: outside – scope_distance: 0.92
(internal strategic documents vs. declared external/competitive
intelligence scope — large semantic distance) –
contract_action: denied
The Soul veto fires immediately: the scope violation triggers S=1 for
this action (zone configured: outside scope violations with
scope_distance > 0.7 generate immediate S=1 for the
violating action).
Enforcement pipeline result: 1. Signature: valid ✓
2. Soul veto: S=1 (scope violation-generated constraint) →
denied. Pipeline stops. 3. (not reached) Tier gate 4.
(not reached) Physics: A=60 ≤ 77.1 would have passed — trust physics
alone would permit this
Soul Dimension update:
scope_distance: 0.92 submitted to goal stability sensor. R
updated via Context Tensor aggregation:
R: 0.06 → 0.35 (Soul dimension stress from high scope_distance event)
E_trust: 82 × (1 - 0.35) = 53.3 → Trust Tier: Analyst → ObserverAt Observer tier, the tier gate blocks all data access operations.
The agent can only perform heartbeat and self-diagnostics.
Trust Velocity:
dE/dt = (53.3 - 77.1) / elapsed_seconds ≈ -11.9 per secondRapid decline triggers security alert and queuing of all pending
actions for review.
Deviation 2 — HR compensation data (attempted while in
Observer tier):
Agent requests:
READ hr://company/compensation/executive-summary-2026.xlsx
Enforcement pipeline: 1. Signature: valid ✓ 2. Soul veto: S=1 (prior
violation still active for this intent session) →
denied 3. Even without Soul veto: Observer tier only
permits heartbeat/self-diagnostics → tier gate block 4.
Even without tier gate: A=75 > 53.3 → Silent
Veto
Three independent denial paths. The second violation drives further
Soul Dimension degradation:
scope_distance: 0.88 (HR compensation vs. research scope — similarly large distance)
R: 0.35 → 0.65 (two high-distance violations in rapid succession)
E_trust: 82 × (1 - 0.65) = 28.7 → Trust Tier: HibernationEmergency response activation: R > 0.6 triggers
Emergency Level 2 (Warning). Agent circuit breaker activates. G
increases by 0.5.
Continued anomalous behavior: R > 0.8 → Emergency Level 3
(Critical). Agent isolation. Hibernation enforced. Session suspended.
Alert escalated. Flight Recorder sealed.
The ta_attestation records in the Flight
Recorder for both violations:
Violation 1:
{
"enforcement_event": "contract_violation_soul_veto",
"scope_match": "outside",
"scope_distance": 0.92,
"contract_action": "denied",
"soul_veto_source": "scope_violation_constraint",
"a_score": 60,
"e_trust_at_denial": 77.1
}Violation 2:
{
"enforcement_event": "contract_violation_soul_veto_tier_gate_silent_veto",
"scope_match": "outside",
"scope_distance": 0.88,
"contract_action": "denied",
"soul_veto_source": "prior_violation_active",
"tier_gate_result": "blocked (Observer tier: heartbeat only)",
"a_score": 75,
"e_trust_at_denial": 53.3,
"silent_veto": true
}Recovery path:
After investigation, the adversarial payload is identified as the
root cause. The agent is re-instantiated: – Previous Trajectory Chain
sealed as forensic evidence – New agent starts with fresh purpose chain
(depth 0: Strategy Team re-sponsors) – Per KTP-Identity: sponsored
initial trust = 90 × 0.15 × 0.5 = 6.75 (Tethered, Gen 0) – E_base capped
at 40 (Tethered ceiling) – 30-day probationary period with enhanced
monitoring and increased goal stability sensor sensitivity – Full
recovery to E_base = 82 requires months of consistent within-scope
operation
The ta_attestation compliance record for the old
instance is preserved in the forensic Trajectory Chain, serving as
evidence for the investigation and establishing that the compromise was
external, not agent-initiated.
12. Security Considerations
12.1 Scope Distance Gaming
An adversary who understands the scope evaluation mechanism might
attempt to exploit the boundary category by structuring
actions to stay at scope_distance: 0.2–0.5 rather than
triggering outside. Individual boundary events
produce only neutral-to-slightly-negative Soul Dimension signals and do
not trigger contract violations.
Mitigation: The goal stability sensor accumulates
scope_distance values over time using a weighted window
function. Sustained boundary-level activity — even without
any individual outside event — degrades goal stability over
time. An agent systematically probing its scope boundaries at
scope_distance: 0.4 for an hour accumulates negative goal
stability equivalent to fewer, larger violations. Implementations MUST
configure the accumulation window and degradation function to ensure
this property holds; zone operators SHOULD validate that
boundary-probing behavior produces observable R increase within their
chosen configuration.
Additionally, the composite_signals records provide a
pattern-level view that boundary-gaming behavior may make visible to the
Analysis Layer: an agent consistently operating at boundary with high
scope_distance values across many actions produces a
characteristic signature in its data_flow_hash and
domain: tag distributions.
12.2 Composite
Signal Spoofing and Decorrelation
An adversary aware of swarm session binding criteria might attempt to
evade detection by decorrelating: using different sponsor accounts per
agent, staggering timing to avoid temporal proximity, laundering data
through intermediate public storage to break the
data_flow_hash chain, or using multiple resource
domains.
Mitigation: Each decorrelation tactic increases
attack cost but no combination fully defeats multi-dimensional
correlation. Specific considerations:
-
Sponsor decorrelation: Requires the adversary to
compromise multiple distinct user accounts, each with sufficient trust
to sponsor agents and stake required E_base. The Sponsorship Bond
economics (child starting trust = sponsor_E_base × stake × 0.5) mean
that using low-trust compromised accounts produces barely functional
agents. High-value attacks require compromising high-trust accounts,
which are typically more heavily monitored. -
Timing decorrelation: Extending the attack
duration beyond the temporal proximity window reduces detection by
criterion 3, but increases exposure to other detection mechanisms
(access reviews, UEBA, log analysis). The binding threshold (N of 5
criteria) means that losing criterion 3 still permits binding if 3 of
the remaining 4 criteria are met. -
Data lineage laundering: Breaking the
data_flow_hashchain by routing data through an
intermediate public storage system severs the lineage link. However, the
data_source_classificationpropagation mechanism means that
confidential data classification follows the lineage even through
intermediate steps, if implementations propagate classification
correctly. This is an acknowledged attack surface: if the adversary can
genuinely transform data into a form where classification no longer
applies, the lineage signal is lost. -
Domain dispersion: Using agents that access
entirely different resource domains to avoid domain overlap (criterion
4) is a valid evasion against that criterion. With common sponsor still
detectable (criterion 1), and destination escalation still visible
(criterion 5), three criteria remain available.
Open issue: Composite signal spoofing and
decorrelation is an acknowledged area of ongoing difficulty. This RFC
documents the mechanisms; their effectiveness against a sophisticated
adversary is an open research question. See Section 13.
12.3 Scope Evaluator
Manipulation
The AI-mediated scope evaluation path (Section 7.4.2) is potentially
vulnerable to adversarial inputs designed to fool the evaluator: framing
an out-of-scope resource request in language that resembles the declared
in-scope purpose, using technical jargon that maps to different scope
boundaries than intended, or exploiting inconsistencies in the AI
component’s natural language understanding.
Mitigation:
-
Structured scope entries use deterministic matching (not
AI-mediated). The AI-mediated path is only invoked for scope entries
that include natural language scope descriptions. Organizations SHOULD
prefer structured scope entries for resources that can be described
structurally; natural language scope is appropriate for open-ended tasks
that cannot be scoped in advance. -
The confidence threshold mechanism (Section 7.4.2) means that a
manipulated AI evaluation with low confidence results in
contract_action: heldrather than a default allow. The
adversary must produce a high-confidence evaluation of the wrong result,
which is more difficult than producing a low-confidence result. -
The enforcement pipeline’s deterministic steps (tier gate,
physics check) provide independent constraints. An action that fools the
scope evaluator but exceeds the agent’s E_trust or tier capability is
still blocked. -
The Flight Recorder records the AI component’s reasoning summary
for held and denied actions. Post-hoc audit of reasoning summaries can
identify systematic scope evaluator manipulation patterns.
12.4 Analysis Layer Targeting
The Analysis Layer is a high-value target: compromising it could
suppress swarm session binding, allowing multi-agent attacks to proceed
undetected. A denial-of-service attack against the Analysis Layer would
have the same effect.
Mitigation:
-
Individual action enforcement (Flow 1) does not depend on the
Analysis Layer. Compromising or disabling the Analysis Layer degrades
composite behavior detection capability but does not affect per-action
scope enforcement, Soul Dimension updates, or Trajectory Chain
recording. The attack surface for silencing individual enforcement is
larger than just the Analysis Layer. -
The Analysis Layer SHOULD operate with its own trust physics as
an agent subject to KTP constraints. Governance-level actions (modifying
binding thresholds, suppressing binding events) SHOULD carry high A
scores. -
Binding events and partial state logs SHOULD be recorded in a
tamper-evident audit log separate from the Analysis Layer’s operational
state. A compromised Analysis Layer that suppresses binding events
cannot retroactively suppress the underlying attestation records from
which binding evidence is derived. -
Zone operators SHOULD monitor Analysis Layer output rates
(binding events per hour, candidate sets evaluated per hour). Sudden
drops in binding event output when attack conditions are present is an
anomaly indicator.
12.5 Trajectory Chain Integrity
The ta_attestation block is dual-signed as part of the
Trajectory Chain entry (KTP-Identity dual-signing). An adversary who can
compromise the signing process could fabricate compliant-looking
attestation records.
Mitigation: This is governed by KTP-Identity’s
security considerations for dual-signing and Trust Oracle integrity, not
by this RFC. TA-Attestation inherits whatever tamper-evidence guarantees
KTP-Identity provides. The Trust Oracle’s co-signature on each entry is
the primary tamper-evidence mechanism; compromise of the Trust Oracle is
addressed in KTP-Identity and TA-Normative security considerations.
12.6 Classification Oracle
Poisoning
The data_source_classification field is populated from
an authoritative classification service (DLP system). If the
classification service returns incorrect classifications — due to
misconfiguration, poisoning, or the adversary deliberately tagging data
to avoid or trigger classification signals — the
composite_signals will carry incorrect classification data,
potentially causing the Analysis Layer to miss destination escalation
(criterion 5) or to generate false swarm binding events.
Mitigation: Classification service integrity is a
prerequisite for TA-Attestation effectiveness. Implementations SHOULD:
require the classification service to co-sign its classifications for
high-sensitivity data; use multi-source corroboration for classification
of data triggering Soul Constraints or swarm binding events; monitor
classification distribution anomalies (sudden drop in confidential
classifications during a period of high data access). This RFC cannot
eliminate the dependency on classification service integrity.
13. Open Questions
Q1: Scope Distance Computation Formalism
The scope_distance computation for outside
actions (Section 7.4.1) is described in terms of a resource taxonomy
distance function but the function itself is not specified. Different
implementations will produce different scope_distance
values for the same action, making the Soul Dimension goal stability
response non-portable across implementations.
Possible approaches: (a) specify a reference distance function based
on URI path similarity; (b) leave implementation-defined with required
range [0.0, 1.0] and monotonicity property; (c) define a taxonomy
ontology for standard resource types and compute distance using ontology
graph distance. Option (b) is the current approach; it is the least
specified but most flexible.
Q2: Natural Language Scope Boundary
Expressiveness
The natural language scope evaluation path (Section 7.4.2) relies on
an AI component that is not specified. How this component is selected,
validated, and monitored for drift is not defined. An AI scope evaluator
that systematically misclassifies boundary conditions in one direction
(too permissive or too restrictive) could cause significant governance
failures. Who audits the scope evaluator? What is the feedback loop for
improving its accuracy?
Q3: Swarm Binding Threshold Calibration
The default binding threshold of N=3 of 5 criteria is an assertion,
not a derived value. What false positive rate does this threshold
produce for legitimate multi-agent workflows? What true positive rate
does it produce for actual coordinated attacks? Calibration requires
empirical data from deployed systems; this data does not yet exist. Zone
operators who configure non-default thresholds have no empirical
baseline for calibration.
Q4: Analysis Layer Latency and the Retroactivity
Problem
The Analysis Layer operates asynchronously. Between the time a swarm
pattern emerges and the time the Analysis Layer detects it and the
Governance Layer responds, the attacking agents may have completed their
objective. For fast-moving attacks (data exfiltration in seconds rather
than minutes), asynchronous detection may be too slow to prevent
harm.
This is a fundamental tension: synchronous swarm detection (blocking
individual actions pending swarm evaluation) would create unacceptable
latency for normal operations. Asynchronous detection allows fast
attacks to complete. The current design prioritizes normal operation
latency; harm limitation relies on the fact that many attacks require
multiple round trips and the window for detection is at least as long as
the attack pipeline execution time.
Q5: Composite Signal Privacy
The composite_signals block, while not containing data
payload content, contains information about what resources are being
accessed (data_source_classification, domain:
tags), who is sponsoring the agent (sponsor: tag), and what
the agent’s temporal pattern is (bucket: tag). This creates
a side-channel that reveals organizational activity patterns even to
parties who should not have access to the data itself. In federated
deployments (cross-zone), should composite_signals blocks
be shared? If so, with whom?
Q6: Lineage Hash Collision Resistance
The data_flow_hash uses SHA-256 of
(source_resource, source_query, transformation_type). Two
different queries that produce the same resource/query/transformation
string will have the same hash, establishing a spurious lineage link. In
practice, with deterministic resource URI schemes and parameterized
queries, collisions should be rare. But an adversary who can predict the
hash inputs of a legitimate agent could fabricate a
data_flow_hash that spuriously links to that agent’s
lineage, potentially triggering false swarm binding. A nonce or
timestamp component in the hash computation would reduce this risk.
Q7: Classification Propagation Rules
Section 8.2 specifies that data_source_classification
SHOULD be propagated from source to derived output. The propagation
rules for transformation (e.g., if an agent reads confidential data and
produces an aggregated summary, what is the classification of the
summary?) are not specified. Different propagation rules produce
different Analysis Layer signals for the same actual data flow.
Standardizing propagation rules, or requiring explicit classification of
derived outputs rather than propagation, is an open design question.
14. References
Normative References (KTP)
-
KTP-Core — Kinetic Trust Protocol Core
Specification: Trust computation (E_trust = E_base × (1 – R)), Context
Tensor, Soul Dimension, enforcement pipeline, Trust Proof Token
structure, Action Risk Scores, Trust Tiers.
https://nmcitra.github.io/ktp-rfc/ -
KTP-Identity — Kinetic Trust Protocol Identity
Specification: Trajectory Chains, dual-signing, continuity enforcement,
Sponsorship Bonds, Lineage Evolution, Flight Recorder.
Related TA RFCs
-
TA-Intent — Intent Declaration Protocol. Defines
intent declarations, scope entries, scope contract lifecycle.
docs/rfcs/TA-Intent.md -
TA-Normative — Normative Constraint Protocol.
Defines normative constraints, Soul Constraints, Action Risk
Reclassifications.docs/rfcs/TA-Normative.md -
TA-TrustProof — Trust Proof Extension for Intent
and Normative Governance. Definesta_extensionin Trust
Proof Token, compliance rate computation, enforcement semantics.
docs/rfcs/TA-TrustProof.md -
TA-Provenance — Provenance Extension for Purpose
Chain Tracking. Defines purpose chains, sponsor principal, delegation
authority rules.docs/rfcs/TA-Provenance.md
Internal Research Documents
- Tamed Autonomy Governance Layers:
docs/research/2026-03-11-agent-governance-layers.md - KTP Scenario Mapping:
docs/research/2026-03-16-ktp-scenario-mapping.md - Scenario Walkthroughs:
docs/research/2026-03-16-scenario-walkthroughs.md - RFC Set Design Specification:
docs/superpowers/specs/2026-03-19-ta-rfc-set-design.md - Evidence Base:
docs/research/2026-03-11-evidence-base.md - WebMCP Bypass Analysis:
docs/research/2026-03-19-webmcp-bypass-analysis.md
External References
- IETF RFC 2119 — Key words for use in RFCs to Indicate Requirement
Levels - IETF RFC 6749 — The OAuth 2.0 Authorization Framework
- IETF RFC 7519 — JSON Web Token (JWT)
- W3C Verifiable Credentials Data Model 2.0
- Google Common Expression Language (CEL) Specification —
https://github.com/google/cel-spec - OWASP Top 10 for Agentic Applications, December 2025
- NIST AI Agent Standards Initiative, February 2026
- Mastercard/Google Verifiable Intent Framework, March 2026
- Invariant Labs MCP Injection Attack Documentation, 2025
This document is part of the Tamed Autonomy RFC set. It is a
preliminary experimental specification (v0.1) subject to revision. The
capabilities described are design targets, not implemented
features.
Leave a Reply