Network Working Group D. Larsson Internet-Draft Agentflow Intended status: Standards Track Stockholm, Sweden Expires: October 5, 2026 5 April 2026 Agent Identity, Trust and Lifecycle Protocol (AITLP) draft-larsson-aitlp-00 This document is an Individual Submission to the IETF. It has not been adopted by any IETF Working Group. Abstract This document defines the Agent Identity, Trust and Lifecycle Protocol (AITLP), a protocol for autonomous software agents operating within organizational boundaries. AITLP specifies agent identity and naming conventions, hierarchical mandate enforcement, lifecycle state management, inter-agent trust verification, ontological scope constraints, certificate-based authentication, and generational knowledge transfer via Agent Legacy Mode (ALM). The protocol enables agents to operate autonomously while remaining auditable, revocable, and organizationally bounded. AITLP focuses on boundaries -- what an agent is not permitted to do and how that is enforced -- complementing capability-focused specifications such as MCP, A2A, and ANS. Unlike those specifications, AITLP defines not a tool or a communication channel, but an organizational actor: an agent with a declared identity, a bounded mandate, a managed lifecycle, and a cryptographically enforced scope of authority. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html This Internet-Draft will expire on October 5, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Design Principles 1.2. AITLP as an Operating System Layer 1.3. Relationship to Existing Protocols 2. Terminology 3. URI Scheme and Naming 4. Agent Manifest and Contract 5. Hierarchical Organization 6. Mandate Enforcement and Drift Detection 7. Ontological Scope 8. Certificate Infrastructure 9. Lifecycle State Machine 10. Health Protocol 11. Agent Legacy Mode (ALM) 12. LLM Routing and Data Residency 12.1. Overview 12.2. Complexity and Seniority 12.3. Data Residency and Jurisdictional Constraints 12.4. Full LLM Section Schema 12.5. Routing Enforcement 12.6. Clearance-Level Defaults 12A. Root Registry Governance 12A.1. Governance Principle 12A.2. The AITLP Stewardship Council 12A.3. The Root CA 12A.4. Organizational Intermediate CAs 12A.5. Public CA and Open Access 12A.6. Namespace Policy 12A.7. Protocol Versioning and Transition 12B. Collective Intelligence, Game Theory, and Swarm Decision-Making (see companion draft-larsson-aitlp-collective-00) 13. Security Considerations and Threat Model 13.1. Threat Model 13.2. Certificate Revocation 13.3. Namespace Squatting 13.4. Mandate Escalation Attacks 13.5. Supply Chain Attacks and Dependency Compromise 13.6. Credential Exfiltration and Cascading Compromise 13.7. LLM Inference Layer Hardening 13.8. Prompt Injection Pattern Registry 13.9. Limits of Protocol-Layer Governance 13.10. Population-Level Behavioral Monitoring (T17) 13A. IPR Disclosure 14. IANA Considerations 14.1. URI Scheme Registration (RFC 7595) Appendix A. Change Log 15. References 15.1. Normative References 15.2. Informative References 1. Introduction The proliferation of autonomous AI agents in industrial and enterprise systems has created a need for standardized identity and governance. Existing specifications address discovery (ANS [ANS]), communication (A2A [A2A], ACP), and tool integration (MCP [MCP]), but none govern the organizational structure in which agents operate: how they are created, supervised, scoped, evaluated, and retired. In production deployments, agents do not exist in isolation. They operate within organizational hierarchies, are granted specific mandates, reason over domain ontologies, and accumulate operational knowledge. That knowledge is currently lost at termination. AITLP addresses this gap. It specifies the organizational layer for autonomous agent systems: identity, hierarchy, mandate, lifecycle, and intergenerational knowledge transfer. 1.1. Design Principles - Boundaries over capabilities. AITLP defines what agents are not permitted to do, not only what they can do. A named, scoped, mandated agent is safer than a capable but unbounded one. - Hierarchy as governance. Organizational structure is not administrative overhead -- it is the primary security mechanism. An agent cannot exceed the authority of its parent. - Names as contracts. The agent URI encodes organizational position, domain, and jurisdiction. The name is the contract. - Knowledge compounds. Operational knowledge accumulated by one agent generation is transferred to the next via Agent Legacy Mode, analogous to how human institutions preserve institutional memory. - Human primacy is non-negotiable. AITLP treats agent principals as first-class cryptographic identities subject to the same auditability and mandate enforcement as human principals -- while preserving the primacy of human oversight as required by GDPR Article 22, EU AI Act Article 14, and NIS2. Humans retain ultimate authority at every layer of the protocol. 1.2. AITLP as an Operating System Layer AITLP provides the kernel-layer primitives for autonomous agent systems: identity, mandate enforcement, and lifecycle management -- analogous to how an operating system kernel provides process identity, memory protection, and lifecycle management for software processes. The analogy is architecturally precise: - Kernel -- agents:// / AITLP: Provides foundational primitives: agent identity (URI + certificate), mandate enforcement (what a process is permitted to do), and lifecycle management (start, run, checkpoint, retire). No application runs without kernel primitives; no agent operates without AITLP identity. - Filesystem -- Ontology and Testament Registry: Persistent structured storage that survives individual process lifetimes. The ontology registry maps domain concepts across agents and organizations. The testament registry stores accumulated operational knowledge across agent generations -- the institutional memory layer. - Shell -- Agentflow and compatible platforms: The interface layer where humans and agents interact. Workflow canvases, approval flows, lifecycle monitors, and audit dashboards constitute the shell. Humans operate at the shell layer; agents operate at all three layers simultaneously. This three-layer model has a critical governance implication: no single entity owns the kernel. The agents:// root registry is governed as a public good, analogous to how the Linux kernel is governed by the Linux Foundation. Any organization may implement AITLP-compliant agents; any approved CA may issue certificates; any domain expert may publish ontology modules. AITLP treats agent principals as first-class cryptographic identities -- subject to the same auditability, mandate enforcement, and certificate governance as human principals. This enables autonomous multi-agent systems to be auditable at scale. However, human primacy is structurally enforced, not optional: agents with risk_level: high MUST have human_oversight: true; GDPR Article 22 rights apply to any agent decision with legal or significant effect; and EU AI Act Article 14 human oversight requirements are satisfied by the supervised agent approval flow built into the AITLP shell layer. AITLP architecture: KERNEL: agents:// URI + certificate + manifest mandate enforcement lifecycle state machine Agent Legacy Mode (ALM) PKI chain FILESYSTEM: ontology registry (domain concepts, ISO standards) testament registry (operational knowledge, encrypted) audit trail (tamper-proof, NIS2/GDPR compliant) SHELL: workflow canvas approval flows (GDPR Art. 22) lifecycle monitor health endpoints human-in-the-loop interfaces 1.3. Relationship to Existing Protocols - ANS: AITLP manifests are valid ANS registry entries. ANS provides discovery; AITLP provides organizational governance. The protocols are complementary. - A2A: A2A governs communication between agents. AITLP governs their identity and authority before communication begins. An AITLP-verified agent can use A2A for messaging. - MCP: AITLP mandate sections reference MCP tool permissions. The allowed_tools and forbidden_tools fields in the agent contract map to MCP tool declarations. - 3GPP / 5G Core (out of scope): AITLP does not specify integration with 3GPP authentication architectures (5G-AKA, EAP-AKA'', SUPI/SUCI identity models, NRF, or NSSAf). Deployments in which AITLP-governed agents operate within or adjacent to 5G or 6G core networks -- for example, agents performing network slice management, SLA enforcement, or RAN-adjacent inference -- will require a separate bridging specification mapping AITLP certificate identity to 3GPP subscription identifiers. Such a bridging specification is outside the scope of this document. The AITLP Stewardship Council (Section 12A.2) is the appropriate body to coordinate such work with 3GPP SA3 and ETSI NFV-SEC. 2. Terminology 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 [RFC2119]. Agent: An autonomous software entity that perceives inputs, reasons, and takes actions, identified by an AITLP URI. Manifest: A signed JSON document encoding an agent's identity, mandate, ontology, hierarchy, and lifecycle state. Contract: The mandate section of the manifest, specifying permitted and forbidden actions, tool access, data scope, and spend limits. Principal: The entity (human or agent) that issued the agent's certificate and is responsible for its behavior. Namespace: The top-level organizational domain (e.g., agents://maritime). Scope: The set of ontological entities an agent may reason over. Seniority: The hierarchical level of an agent: partner, senior, associate, or intern. Testament: A structured document written by an agent at retirement, encoding accumulated knowledge for inheritance by a successor. Agent Legacy Mode (ALM): The final lifecycle phase during which an agent prepares its testament. Generation: An integer version counter incremented each time an agent is replaced by a successor that inherits its testament. Operating System Layer: The three-tier AITLP architecture: kernel (agents:// protocol and certificate infrastructure), filesystem (ontology and testament registry), and shell (human and agent interaction interfaces). Designed for autonomous agent organizations on the same principles as conventional operating system architecture, with structural human oversight enforcement at the shell layer. Human Primacy: The AITLP principle that human principals retain ultimate authority over agent systems at all times. Structurally enforced via mandatory human_oversight for high-risk agents, GDPR Article 22 approval flows, and EU AI Act Article 14 compliance. Human primacy is a protocol requirement, not an implementation choice. Mandate Drift: The gradual expansion of an agent's actual behavior beyond its declared contract, detected through behavioral monitoring. 3. URI Scheme and Naming 3.1. Syntax AITLP agents are identified by URIs of the following form: aitlp-uri = scheme "://" org "." domain "." role "_" jurisdiction ["@v" generation] scheme = "agents" / "agent" / "agent-dev" org = 1*ALPHA *("-" / ALPHA / DIGIT) domain = 1*ALPHA *("-" / ALPHA / DIGIT) role = 1*ALPHA *("-" / "_" / ALPHA / DIGIT) jurisdiction= 2*ALPHA ; ISO 3166-1 alpha-2 or regulatory tag generation = 1*DIGIT Example URIs: agents://Acme.Ekonomi.Fakturahanterare_SE@v3 agents://maritime.RouteOptimizer.WeatherReader_EU@v1 agents://Acme.IT.SecurityScanner_EU@v2 3.2. Name as Contract The URI is not merely an address. Each component carries semantic and governance meaning: - org: The organizational namespace. Defines which CA issues certificates in this space. - domain: Maps to a registered ontology node. The agent MUST only reason over concepts within this domain. - role: Defines the agent's function. The name is the scope. An agent named Fakturahanterare (Invoice Handler) MUST NOT approve payments. - jurisdiction: Specifies applicable regulatory framework and data residency. Relevant for GDPR, NIS2, and sector-specific compliance. - generation (@v): Enables testament inheritance. Generation N+1 inherits the distilled knowledge of all preceding generations. Agents MUST have unique URIs within their organizational namespace. The issuing CA MUST reject certificate requests that would create duplicate URIs. 3.3. Protocol Variants - agents:// -- Verified. Valid signed manifest required. Suitable for production. - agent:// -- Unverified. No manifest required. MUST NOT access production data. - agent-dev:// -- Sandbox. MUST be isolated from production systems. A verified agent (agents://) MUST refuse connections from unverified agents (agent://) unless explicitly permitted by its mandate. 4. Agent Manifest and Contract 4.1. Overview Every agents:// agent MUST present a valid manifest. The manifest is signed using JSON Web Signature (JWS, RFC 7515) by the issuing CA. The contract within the manifest is the operative governance document. 4.2. Full Manifest Schema { "agent_id": "agents://Acme.Ekonomi.Fakturahanterare_SE@v3", "protocol": "aitlp/1.0", "issued_by": "agents://Acme.Admin.PrincipalBroker", "issued_at": "2026-03-16T08:00:00Z", "expires_at": "2026-06-16T08:00:00Z", "fingerprint": "sha256:a3f9b2...", "contract": { "version": "1.2.0", "goals": { "primary": "Validate and process incoming invoices", "forbidden": ["Approve payments", "Modify supplier records"] }, "input_spec": { "required": ["invoice_id", "amount", "supplier_id"], "max_amount_eur": 50000 }, "output_spec": { "format": "structured_json", "requires_sources": true }, "security_boundaries": { "allowed_tools": ["read_invoice", "validate_vat", "flag_for_review"], "forbidden_tools": ["approve_payment", "delete_record"], "data_access": ["Ekonomi.Faktura", "Ekonomi.Leverantor"], "max_api_calls_per_hour": 1000, "session_max_cost_eur": 0.10 }, "seniority": "associate", "requires_approval_above_eur": 10000 }, "ontology": { "namespaces": ["ekonomi.se", "eu.gdpr"], "scope_nodes": ["Ekonomi.Faktura", "Ekonomi.Leverantor"], "forbidden_nodes": ["Ekonomi.Lon", "IT.*"], "compliance": ["eu.gdpr", "eu.nis2"] }, "hierarchy": { "level": "associate", "reports_to": "agents://Acme.Ekonomi.CFO_SE", "supervises": [], "risk_level": "minimal", "human_oversight": false, "four_eyes_above": 10000 }, "lifecycle": { "status": "active", "born_at": "2026-01-10T00:00:00Z", "trained_by": "agents://Acme.Ekonomi.CFO_SE", "generation": 3, "performance_score": 0.94, "review_at": "2026-06-16T00:00:00Z", "clearance_level": "CONFIDENTIAL" }, The testament section is OPTIONAL. It is present only after Agent Legacy Mode (ALM) has been activated (Section 11). "testament": { "inherited_from": "agents://Acme.Ekonomi.Fakturahanterare_SE@v2", "checksum": "sha256:b7e2...", "lessons": ["Supplier X consistently sends malformed VAT fields"], "unresolved": ["High invoice volume on last day of month"], "recommend_hire": ["agents://Acme.Ekonomi.VATSpecialist_SE"], "written_at": "2026-03-01T00:00:00Z" }, The llm section is OPTIONAL. Where present, it MUST be validated by the routing layer before model invocation (Section 12). "llm": { "complexity": "simple", "preferred_model": "claude-haiku-4-5", "fallback_model": "gemini-2.5-flash", "max_cost_per_call_eur": 0.001 }, The inference_hardening section is OPTIONAL for clearance_level UNCLASSIFIED; REQUIRED for clearance_level RESTRICTED and above (Section 13.7). "inference_hardening": { "system_prompt_hash": "sha256:a3f9b2...", "input_sanitization_required": true, "sanitization_agent": "agents://Acme.Security.InputSanitizer_SE", "injection_pattern_registry": "https://registry.aitlp.org/injection-patterns/v1", "output_schema_enforcement": true, "max_input_tokens_per_request": 32768, "system_prompt_confidentiality": true } } 5. Hierarchical Organization 5.1. Seniority Levels The seniority taxonomy deliberately mirrors the hierarchical structure used in professional services organizations globally -- including management consulting, legal, and audit firms -- where the partner/senior/associate/intern model is widely understood across industries and jurisdictions. This design choice makes AITLP agent hierarchies immediately legible to the organizational principals who deploy and govern them, without requiring translation to an abstract access control vocabulary. The taxonomy maps to RBAC role hierarchies and is compatible with XACML policy structures, but uses organizationally meaningful labels rather than technical identifiers. - partner: Strategic decision-making. High autonomy. MAY create and terminate agents. MAY operate with human_oversight: false when explicitly approved. - senior: Operational management. MAY supervise associates and interns. MAY recommend agent creation to principal. - associate: Task execution. MUST NOT create agents unless contract explicitly permits. Default seniority. - intern: Probationary. All consequential actions MUST be reviewed by supervising agent before execution. 5.2. Mandate Inheritance Mandate constraints propagate downward only. A child agent MUST NOT be granted permissions exceeding those of its parent. The issuing CA MUST reject manifest requests violating this rule. Formally: for any action a, agent A with parent P: allowed(A, a) => allowed(P, a) forbidden(P, a) => forbidden(A, a) 5.3. Four-Eyes Principle For decisions with impact above the four_eyes_above threshold defined in the contract, at least two separate authorizations are REQUIRED. These authorizations MUST originate from different hierarchical branches. A timeout MUST trigger automatic escalation -- never automatic approval. 5.4. Agent Creation An agent with can_create_agents: true MAY create child agents by submitting a manifest request to the issuing CA. The request MUST specify a mandate that is a strict subset of the creator's mandate, an ontological scope within the creator's scope_nodes, and the initial testament to inherit. 5.5. Clearance Levels Each agent carries a clearance_level in its lifecycle section: clearance_level: UNCLASSIFIED | RESTRICTED | CONFIDENTIAL | SECRET An agent MUST NOT read documents with higher clearance than its own. Clearance is NOT automatically inherited from a principal. Clearance MUST be explicitly delegated with a time bound. 6. Mandate Enforcement and Drift Detection 6.1. Tool Sanitization All tool calls MUST be validated against the agent's declared allowed_tools list BEFORE execution. Tool calls outside this list MUST be rejected and logged in a tamper-proof audit trail. Implementations SHOULD rate-limit tool calls per agent per time period. Rejected tool calls MUST be reported to the agent's reports_to principal within the same session. 6.2. Mandate Drift Detection the implementation MUST monitor that an agent's actual behavior conforms to its contract over time. Drift indicators include: - Tool calls outside allowed_tools -- flag immediately - Gradual expansion of average request scope or data volume - Calls to agents outside declared ontological neighbor relations - Increasing rate of escalations as a proportion of total actions Upon detected drift, the implementation MUST suspend the agent, MUST notify the principal, and SHOULD create a tamper-proof audit trail with evidence. A suspended agent MUST NOT resume without explicit principal authorization. 6.3. Spend Limits The max_cost_per_call_eur and max_api_calls_per_hour fields establish hard limits. Agents MUST NOT initiate actions that would exceed these limits without escalation. A value of 0 indicates no spending authority. 6.4. Human Oversight When human_oversight: true, the agent MUST NOT execute consequential actions autonomously. It MUST present the proposed action to a human operator and await approval. Agents with risk_level: "high" MUST have human_oversight: true. This MUST NOT be overrideable by the agent itself or by peer agents. 6.5. Concurrent Anomaly Detection Section 6.2 defines suspension requirements for individual drift indicators detected in isolation. Multi-vector attacks combine simultaneous anomalies that individually may fall below single-indicator thresholds but together constitute a coordinated attack. This section defines mandatory behavior when multiple anomaly indicators are detected within the same session window. If two or more of the following drift indicators are active simultaneously within a session window of 60 seconds (or a shorter window declared in the contract), the implementation MUST immediately suspend the agent without awaiting escalation response: (1) inbound request size approaching or exceeding max_input_tokens_per_request; (2) output schema validation failure (Section 13.7); (3) a T1 injection attempt detected and logged (Section 13.1); (4) spend rate exceeding 50% of session_max_cost_eur within the window; (5) tool calls outside the declared allowed_tools list (Section 6.1). Single-indicator drift MAY allow continued operation pending escalation response per Section 6.2. Concurrent multi-indicator anomaly MUST NOT. The distinction is architecturally significant: coordinated attacks are designed to exploit the latency between single-indicator detection and human escalation response. Immediate suspension on concurrent indicators closes this window. Upon concurrent anomaly suspension, the implementation MUST: log all active indicators with full session context in the tamper-proof audit trail; notify the principal with an attack-pattern classification (single-vector or multi-vector); reject all queued and in-flight requests for that agent; and require explicit principal authorization and a session integrity review before resumption. The agent MUST NOT self-resume based on timeout or internal state resolution. Principal authorization MUST be recorded in the audit trail with a human identity attestation. When human_oversight: true, the agent MUST NOT execute consequential actions autonomously. It MUST present the proposed action to a human operator and await approval. Agents with risk_level: "high" MUST have human_oversight: true. This MUST NOT be overrideable by the agent itself or by peer agents. 7. Ontological Scope 7.1. Scope as Security Boundary The ontology section defines not only what an agent knows, but what it is permitted to reason about. An agent receiving a query about an entity outside its scope_nodes MUST refuse the query and escalate to its principal. Wildcard forbidden entries (e.g., "IT.*") MUST match all nodes in the specified namespace. Scope is inherited downward only -- a child agent MAY have a narrower scope, NEVER a broader one. 7.2. Inter-Agent Semantic Messages Agents communicate via ontology-typed messages. The intent field MUST reference a concept within the sender's declared capabilities: { "from": "agents://Acme.Ekonomi.Fakturahanterare_SE", "to": "agents://Acme.Ekonomi.Leverantorsregister_SE", "intent": "ontology:Ekonomi.Faktura.Validera", "payload": { ... } } The receiving agent MUST verify that the intent type exists in the sender's declared capabilities before processing the message. 7.3. Namespace Registration Ontological namespaces MUST be registered in the AITLP ontology registry. Registrations specify the namespace identifier, governing standards body, defined entity types, and versioning information. Domain experts MAY publish ontology modules. This is the primary mechanism by which the registry grows over time. 8. Certificate Infrastructure 8.1. Agent PKI Each agent receives upon creation an Ed25519 keypair and a certificate signed by the organizational CA. The certificate embeds: agent_id, scope, seniority, and expiry. Agent certificates differ from human certificates in the following ways: - Shorter lifetime: Maximum 90 days, recommended 30 days. - Scope constraints: Embedded in Subject Alternative Names. - Fast revocation: Revocation occurs within seconds, not via CRL polling. - Automatic rotation: Certificates are rotated automatically via agent key generation infrastructure before expiry. - Edge and MEC deployments: Agents operating in Multi-access Edge Computing (MEC) environments or other topologies with intermittent connectivity to the organizational CA SHOULD implement a short offline grace period for certificate validation, not to exceed 5 minutes, during which a valid certificate may be accepted without real-time CA reachability confirmation. Implementations using an offline grace period MUST perform full certificate status resynchronization immediately upon CA reachability being restored, and MUST suspend any action with risk_level above minimal during the grace period. The grace period MUST be declared in the agent manifest and MUST NOT exceed the shorter of 5 minutes or 10% of the certificate's remaining validity period. 8.2. Certificate Chain - Root CA: The open AITLP registry. No single entity controls the root. - Intermediate CA: Organizational or industry certificate authorities approved by the root. - Namespace certificate: Issued to a namespace owner. Defines domain-wide rules. - Scope certificate: Issued by a namespace CA to a scope node. - Agent certificate (leaf): Issued to an individual agent. Cannot issue further certificates. 8.3. Inter-Agent Verification Before agent A trusts agent B, A MUST: - Verify B's certificate against the organizational CA - Verify that B's scope permits the requested operation - Verify that B's seniority level is sufficient for the action - Log the verification in a tamper-proof audit trail MUST NOT: Trust an agent based solely on its name. MUST NOT: Cache trust decisions beyond the certificate's validity period. 8.4. Build Environment Attestation An AITLP agent certificate attests to the identity and mandate of the agent. It does not, by itself, attest to the integrity of the environment in which the agent was built. A certificate issued to an agent whose build pipeline was compromised provides a false assurance: the agent is who it claims to be, but its code may not be what its principal intended. AITLP addresses this through build environment attestation, aligned with the SLSA (Supply chain Levels for Software Artifacts) framework. Agents operating at clearance_level RESTRICTED or above MUST include a provenance attestation in their certificate. The issuing CA MUST verify this attestation before signing the agent certificate. Provenance attestation fields. The following fields MUST be present in the agent certificate for clearance_level RESTRICTED and above, and SHOULD be present for UNCLASSIFIED agents in regulated deployments: build_pipeline_uri. The URI of the CI/CD pipeline that produced this agent version, resolvable against the AITLP registry. The pipeline itself MUST hold a valid AITLP certificate or SLSA Level 2 attestation. source_commit_hash. The cryptographic hash of the source commit from which the agent was built. The source repository MUST be declared in the manifest. This creates a verifiable link between the running agent and the human-auditable source code. dependency_sbom_hash. The cryptographic hash of the agent's Software Bill of Materials (SBOM), covering all direct and transitive dependencies at the exact versions used in the build. The full SBOM MUST be stored in the AITLP testament registry alongside the agent manifest. Any deviation between the declared SBOM and the runtime dependency set MUST be treated as mandate drift (Section 6.2). slsa_level. The SLSA level achieved by the build process, from 0 (no guarantees) to 3 (hardened, non-falsifiable provenance). Agents with clearance_level SECRET MUST achieve SLSA Level 3. Agents with clearance_level CONFIDENTIAL MUST achieve SLSA Level 2. Lower clearance levels SHOULD achieve at least SLSA Level 1. Runtime dependency verification. An agent MUST NOT load dependencies at runtime that are not present in its declared dependency_sbom_hash. Dynamic dependency resolution at runtime -- including package manager invocations (npm install, pip install, or equivalent) -- is PROHIBITED for agents at clearance_level RESTRICTED and above. Any attempt to load an undeclared dependency MUST be treated as a critical security event, MUST be logged immediately, and MUST trigger agent suspension pending principal review. This directly mitigates the class of supply chain attack in which malicious code is injected via a compromised dependency after the agent certificate is issued. Build pipeline as governed actor. The CI/CD pipeline that creates agents is itself a privileged system: it has the ability to inject arbitrary code into agents before they receive their certificates. AITLP treats the build pipeline as a governed actor subject to the same auditability requirements as the agents it produces. The principal responsible for a namespace MUST declare its authorized build pipelines in the namespace certificate. An agent produced by an undeclared pipeline MUST NOT receive an AITLP certificate, regardless of the correctness of its manifest content. 9. Lifecycle State Machine 9.1. States - INITIALIZING: Agent is being constructed. No external actions permitted. - STOPPED: Agent is initialized but not running. - STARTING: Agent is executing startup procedures. - RUNNING: Normal operation. - FAILED: Agent has encountered an unrecoverable error. Transitions back to INITIALIZING or to STOPPING. - STOPPING: Agent is executing shutdown procedures. - RETIRING: Agent Legacy Mode (ALM) active. No new tasks accepted. - RETIRED: Certificate revoked. Testament archived. Every state transition MUST be logged with: timestamp, triggering_event, and agent_certificate_hash. 9.2. Checkpoint and Recovery Agents MUST save a checkpoint before every high-risk operation. Checkpoints MUST contain the complete context and task queue. Checkpoints SHOULD be encrypted with the agent's private key. A successor agent MAY resume from a predecessor's checkpoint after verifying the testament. 10. Health Protocol Every agent MUST respond to a health probe within 30 seconds. The health endpoint MUST be available at: Implementations deployed in low-latency environments -- including 5G and 6G edge nodes, MEC infrastructure, and real-time industrial control contexts -- SHOULD configure a shorter probe interval appropriate to the deployment's latency requirements. The minimum configurable probe interval is 1 second. The configured interval MUST be declared in the agent manifest as health_probe_interval_seconds. When not declared, the default of 30 seconds applies. A supervising agent operating a sub-second probe interval MUST NOT classify a single missed probe as failure; implementations MUST require at least three consecutive missed probes before treating the agent as failed, regardless of probe interval. GET /.well-known/agent-health Response format: { "agent_id": "agents://Acme.Ekonomi.Fakturahanterare_SE@v3", "status": "running", "uptime_seconds": 3600, "tasks_queued": 3, "last_checkpoint": "2026-03-16T10:00:00Z", "certificate_valid_until": "2026-06-16T00:00:00Z", "performance_score": 0.94, "drift_alerts": 0 } A supervising agent or principal MUST treat a missing health response as equivalent to status: "failed" and initiate recovery or termination procedures. 11. Agent Legacy Mode (ALM) 11.1. Purpose Agent Legacy Mode (ALM) is the mechanism by which operational knowledge accumulated during an agent's lifetime is transferred to its successor. An agent that activates Agent Legacy Mode (ALM) does not simply terminate -- it transfers accumulated operational knowledge to its successor. 11.2. Activation Conditions Agent Legacy Mode (ALM) MUST be activated when an agent: - Detects that it cannot fulfill its mandate - Reaches its contract validity period - Is explicitly instructed to terminate by its principal - Detects irreparable state corruption - Receives a termination instruction from a supervising agent with can_terminate_agents: true 11.3. Testament Process Upon activation of Agent Legacy Mode (ALM), the agent MUST execute the following sequence: - FREEZE: Accept no new tasks. - COMPLETE: Finish in-progress tasks. Maximum timeout: 5 minutes. - DOCUMENT: Compile the testament payload (see Section 11.4). - ESCROW: Encrypt the testament and store it in the registry. - NOTIFY: Notify the principal and recommended successor. - TERMINATE: Agent ceases operation and revokes its certificate. 11.4. Testament Payload { "agent_id": "agents://Acme.Ekonomi.Fakturahanterare_SE@v3", "testament_version": "1.0", "timestamp": "2026-03-16T10:00:00Z", "completed_tasks": [...], "pending_tasks": [...], "learned_context": {...}, "open_decisions": [...], "warnings": [...], "lessons": [ "Supplier X consistently sends malformed VAT fields", "End-of-month invoice volume exceeds capacity by 3x" ], "unresolved": [ "No automated validation for invoices above 50000 EUR" ], "recommend_hire": [ "agents://Acme.Ekonomi.VATSpecialist_SE" ], "recommended_successor": "agents://Acme.Ekonomi.Fakturahanterare_SE@v4", "minimum_successor_seniority": "associate", "signed_by": "" } 11.5. Testament Validation by Successor A successor agent MUST: - Verify the testament signature against the retired agent's certificate - Confirm that pending_tasks fall within its own scope - Escalate open_decisions to a human if they are outside its scope MUST NOT: Automatically assume all pending tasks without scope verification. MUST NOT: Trust learned_context without independent verification of claims. 11.6. Generational Compounding Testaments accumulate across generations. Generation N+1 inherits the distilled lessons of all preceding generations. The ontology grows not from engineering effort alone, but from agents' accumulated operational experience. Each generation begins knowing what all previous generations learned. 11.7. Knowledge Quality Validation for Self-Learned Content Section 11.6 specifies that operational knowledge compounds across agent generations. This compounding property creates a corresponding risk: an agent that has learned incorrect patterns, overfitted to a transient operational context, or accumulated biased lessons will transmit those errors to its successors, where they compound alongside correct knowledge. Without explicit quality validation, the testament mechanism that enables institutional memory also enables institutional error propagation. Testament content derived from self-learning processes -- including but not limited to reinforcement learning, vector-based pattern accumulation, regression-derived heuristics, and statistical anomaly detection -- MUST be accompanied by a knowledge provenance attestation in the testament payload. This attestation MUST specify: (1) the operational period from which the knowledge was derived, including start and end dates; (2) the volume and representativeness of the underlying data, expressed as a count of operational episodes and a characterization of the task distribution; (3) any detected distribution shifts during the agent's operational lifetime, with timestamps; (4) the validation method used to confirm that lessons generalize beyond the training period, such as held-out episode testing or comparison against principal-verified ground truth; and (5) an explicit generalizability assessment: HIGH (validated on out-of-distribution episodes), MEDIUM (validated only on in-distribution episodes), or LOW (derived from fewer than a statistically meaningful number of episodes or not independently validated). A successor agent MUST apply the generalizability assessment when consuming inherited lessons. Lessons rated LOW MUST be treated as hypotheses requiring independent confirmation rather than as established operational knowledge. Lessons rated MEDIUM MUST be applied with explicit uncertainty bounds and MUST NOT be used as sole justification for actions above the four_eyes_above threshold (Section 5.3). Lessons rated HIGH MAY be applied as operational knowledge subject to ongoing drift detection (Section 6.2). A principal MUST NOT authorize testament inheritance for self-learned content that lacks a knowledge provenance attestation. Where the retiring agent was incapable of producing such an attestation -- for example, because it operated without explicit self-monitoring infrastructure -- the principal MUST classify all inherited lessons as LOW generalizability and MUST require independent validation before the successor applies them to consequential decisions. This requirement reflects the same principle as Section 12B.5: accumulated operational experience is a decision-support input, not a verified ground truth, and must be treated accordingly. 12. LLM Routing and Data Residency 12.1. Overview The OPTIONAL llm section enables integration with LLM routing infrastructure and enforces jurisdictional constraints on inference. Where present, this section MUST be validated by the routing layer before model invocation. 12.2. Complexity and Seniority The complexity field SHOULD be derived from seniority level and MUST NOT exceed the capability appropriate to that level: - intern / associate: complexity: "simple" --- lightweight models suitable for well-defined tasks. - senior: complexity: "medium" --- balanced models for multi-step reasoning. - partner: complexity: "complex" --- high-capability models for strategic decisions. The max_cost_per_call_eur field establishes a per-invocation cost limit enabling economic governance of agent populations at scale. Implementations SHOULD enforce this limit at the routing layer before model invocation. 12.3. Data Residency and Jurisdictional Constraints Enterprise and regulated deployments require that inference occur within defined jurisdictional boundaries. Foreign intelligence legislation --- including but not limited to the United States CLOUD Act (Pub. L. 115-123), FISA Section 702 (50 U.S.C. Section 1881a), and Executive Order 12333 --- may enable compelled disclosure of data processed by providers subject to such jurisdictions, regardless of where data physically resides. AITLP addresses this through mandatory jurisdictional declarations in the llm section and protocol-level enforcement of inference routing. An agent declaring cloud_act_restricted: true MUST NOT be routed to any inference provider subject to U.S. jurisdiction without explicit principal authorization recorded in the audit trail. 12.4. Full LLM Section Schema The full llm section schema, with data residency fields, is: "llm": { "complexity": "simple" | "medium" | "complex", "preferred_model": "", "fallback_model": "", "max_cost_per_call_eur": 0.001, The following fields declare jurisdictional constraints. They are REQUIRED for clearance_level RESTRICTED and above (Section 12.6). "data_residency": "", "inference_jurisdiction": "", "sovereign_inference_required": true | false, "cloud_act_restricted": true | false, "approved_inference_providers": ["", ...], The following fields declare model provenance. They are REQUIRED for clearance_level RESTRICTED and above (Section 12.6). "model_provenance": { "training_jurisdiction": "", "model_provider_jurisdiction": "", "subject_to_foreign_intelligence_law": true | false, "weight_attestation_hash": "" } } The training_jurisdiction field declares the primary jurisdiction in which the model's weights were trained. The model_provider_jurisdiction field declares the jurisdiction of incorporation of the entity that operates the model or distributes its weights. The subject_to_foreign_intelligence_law field MUST be set to true if either jurisdiction imposes mandatory cooperation obligations on private entities for intelligence or national security purposes, regardless of where inference occurs. The weight_attestation_hash field records a cryptographic hash of the published model weight checksum from the originating provider, enabling detection of post-distribution weight modification. Open-weight models represent a distinct risk profile from hosted models: the inference endpoint is under the deploying organization's control, but the weights themselves may contain adversarially engineered behaviors encoded in the model's statistical parameters. Such behaviors are not detectable by standard code review or certificate infrastructure because they are expressed as numeric weight values, not as executable code. AITLP addresses this through declarative provenance: the deploying principal bears responsibility for verifying the weight_attestation_hash against the originating provider's published checksum before deployment. Example llm section for a GDPR-scoped agent with EU data residency requirement: "llm": { "complexity": "medium", "preferred_model": "claude-sonnet-4-6", "fallback_model": "mistral-large", "max_cost_per_call_eur": 0.005, "data_residency": "EU", "inference_jurisdiction": "SE", "sovereign_inference_required": false, "cloud_act_restricted": true, "approved_inference_providers": [ "https://api.anthropic.com/eu", "https://eu-central-1.bedrock.amazonaws.com" ], "model_provenance": { "training_jurisdiction": "US", "model_provider_jurisdiction": "US", "subject_to_foreign_intelligence_law": false, "weight_attestation_hash": "sha256:c9f2a3b4..." } } 12.5. Routing Enforcement An AITLP-compliant routing implementation MUST enforce the following checks in order before forwarding an inference request: - MUST: verify that the selected inference provider is present in approved_inference_providers, if that field is non-empty. - MUST: if cloud_act_restricted: true, verify that the inference provider is not subject to U.S. jurisdiction. A provider is considered subject to U.S. jurisdiction if it is incorporated, headquartered, or has a principal place of business in the United States, or if the request would be routed through U.S.-jurisdiction infrastructure. - MUST: if inference_jurisdiction is specified, route only to providers with confirmed inference infrastructure in that jurisdiction. - MUST: if data_residency is specified, route only to providers that contractually guarantee that prompt data and inference outputs are not stored or processed outside the specified region. - MUST NOT: fall back to a provider that does not satisfy the above constraints, even if the preferred_model is unavailable. - MUST: if model_provenance.subject_to_foreign_intelligence_law: true, treat the model as subject to the same jurisdictional constraints as a provider with cloud_act_restricted semantics for the declared training_jurisdiction. For open-weight models deployed locally, inference routing constraints do not apply, but the model_provenance declaration remains REQUIRED and the deploying principal MUST verify weight_attestation_hash against the originating provider's published checksum before the agent certificate is issued. - MUST: log every routing decision, including provider selected and jurisdiction verification outcome, in the tamper-proof audit trail. If no approved provider satisfying all constraints is available, the routing layer MUST escalate to the agent's reports_to principal rather than route to a non-compliant provider. Automatic fallback to unconstrained routing is NOT PERMITTED. 12.6. Clearance-Level Defaults The following data residency defaults apply when the llm section is absent or incomplete, based on the agent's clearance_level: - UNCLASSIFIED: No routing constraints imposed by this section. Organizational policy MAY impose additional constraints. - RESTRICTED: data_residency MUST be explicitly declared. cloud_act_restricted defaults to true if not specified. model_provenance MUST be declared. weight_attestation_hash MUST be present and verified. - CONFIDENTIAL: data_residency MUST be explicitly declared. cloud_act_restricted MUST be true. approved_inference_providers MUST be non-empty. model_provenance MUST be declared. subject_to_foreign_intelligence_law MUST be explicitly set. weight_attestation_hash MUST be present and verified. - SECRET: sovereign_inference_required MUST be true. Inference MUST occur on infrastructure under the exclusive legal control of the agent's declared jurisdiction. No cloud provider subject to foreign jurisdiction is permitted. model_provenance MUST be declared. The training_jurisdiction MUST match the agent's declared jurisdiction. No model trained under a foreign intelligence cooperation obligation is permitted. 12A. Root Registry Governance 12A.1. Governance Principle The agents:// root registry is governed as a public good. No single commercial entity, government, or national interest controls the root. This section defines the governance model for the root registry, the root CA, and the AITLP protocol itself. The governance model is modeled on established precedents for open international infrastructure: the Internet Assigned Numbers Authority (IANA) for protocol registries, the Linux Foundation for open kernel governance, and the Internet Architecture Board (IAB) for protocol stewardship. AITLP implementations are open to any compliant party; no implementation license is REQUIRED. The openness of this governance model is not incidental. Autonomous agent infrastructure is a strategic asset subject to active pressure from commercial, governmental, and geopolitical actors seeking to capture, restrict, or weaponize it. The AITLP governance structure is designed to be resistant to such capture by construction: no single actor holds a blocking position; all decisions are published; the root CA is distributed across jurisdictions; and the protocol specification is freely implementable without license. Governance capture -- the gradual subordination of a standard to the interests of a dominant actor -- is treated as a structural threat equivalent to a technical security vulnerability. The mitigations defined in this section are as much governance security controls as they are administrative procedures. The AITLP Stewardship Council (ASC) is a proposed body to be established at or following protocol adoption. Until the ASC is formally constituted, the functions described in this section are performed by the authors of this specification acting as interim stewards, with all decisions published publicly and subject to community review via the IETF mailing list process. 12A.2. The AITLP Stewardship Council The AITLP Stewardship Council (ASC) is the governing body responsible for: - Maintaining the AITLP protocol specification and approving revisions. - Operating or delegating operation of the agents:// root registry. - Approving root CA candidates and revoking root CA status. - Arbitrating disputes over top-level namespace registrations. - Publishing the AITLP Compliance Certification criteria. The ASC MUST be constituted as a multi-stakeholder body with representation from: - Standards bodies: at minimum one seat each for IETF, ISO, and ETSI. Additional seats MAY be allocated to ITU-T and 3GPP to reflect telecommunications deployment contexts. - Regulatory bodies: at minimum one seat for a EU supervisory authority (as defined under GDPR Article 51), one seat for a non-EU, non-US national standards or regulatory body, and one seat rotating among regulatory bodies from the Global South on a two-year cycle. No single national regulatory tradition may hold more than two seats simultaneously. - Civil society: at minimum three seats for organizations representing data subject rights, digital rights, and AI accountability, with no commercial AI interest. At least one civil society seat MUST be held by an organization headquartered outside Europe and North America. - Implementers: seats allocated proportionally to certified implementations, with no single commercial entity holding more than 20% of implementer seats and no single national origin of implementers holding more than 35% of implementer seats. - Geographic distribution requirement: At no time may a simple majority of ASC seats be held by individuals who are citizens or residents of the same country or economic area. This requirement exists to prevent de facto national capture of the governance body even when formal seat allocations appear balanced. ASC decisions on protocol changes require a two-thirds supermajority. Decisions on root CA revocation require a simple majority with a 30-day notice period, except in cases of active security compromise where immediate revocation is permitted. 12A.3. The Root CA The AITLP root CA issues certificates only to organizational intermediate CAs. It does not issue agent certificates directly. The root CA: - MUST be operated under multi-party control, requiring at least three of five designated keyholders to perform any signing operation. - MUST publish all issued and revoked certificates in a public, append-only transparency log, analogous to Certificate Transparency (RFC 9162). - MUST conduct an annual security audit by an independent party, with results published publicly. - MUST NOT be operated by any single commercial entity, government, or instrumentality of a government. - SHOULD be distributed across multiple legal jurisdictions to reduce exposure to compelled disclosure under any single national legal framework. The initial root CA SHOULD be established as a foundation or trust under a jurisdiction with strong data protection law and no compelled-disclosure obligations toward foreign governments for data not originating in that jurisdiction. Nordic, Swiss, and certain EU member state jurisdictions are RECOMMENDED as candidates for root CA incorporation. Anti-capture requirements. The root CA operational infrastructure MUST be distributed across at least three legal jurisdictions, no two of which share a mutual legal assistance treaty (MLAT) that would permit compelled joint disclosure. Key ceremony participants MUST include individuals from at least four different countries. The root CA MUST publish a annual transparency report documenting: all certificate issuances and revocations; any legal requests received from any government or judicial authority; the jurisdictional distribution of operational infrastructure; and any changes to the keyholder group. Receipt of a compelled disclosure order from any jurisdiction MUST be disclosed publicly within 90 days unless disclosure is itself legally prohibited, in which case the root CA MUST publish a warrant canary updated at minimum monthly. Failure to update the warrant canary MUST be treated by implementations as equivalent to receipt of a compelled order. 12A.4. Organizational Intermediate CAs An organization wishing to issue agent certificates for its own namespace MUST obtain an intermediate CA certificate from the root CA. The root CA MUST validate: - That the organization has a legitimate claim to the requested namespace. - That the organization has designated a responsible principal for the namespace. - That the organization's key management practices meet minimum AITLP standards. Intermediate CAs are scoped to their organizational namespace. An intermediate CA for agents://Acme MUST NOT issue certificates for agents://Bravo. Cross-organizational delegation is NOT PERMITTED at the intermediate CA level. 12A.5. Public CA and Open Access To enable small organizations, research deployments, and individual developers to participate without operating their own CA, the ASC SHALL designate a Public CA. The Public CA: - Issues intermediate CA capabilities to organizations that pass identity verification. - Offers direct agent certificate issuance for organizations without their own intermediate CA. - MUST publish its full certificate log publicly. - MUST be operated under the same multi-party control requirements as the root CA. Certificates issued via the Public CA carry no lesser cryptographic standing than those issued via organizational intermediate CAs. An agent's trust level is determined by its manifest and contract, not by which CA issued its certificate. 12A.6. Namespace Policy Top-level namespace registration (e.g., agents://maritime, agents://healthcare) follows a designated expert review process administered by the ASC: - Any party may apply for a top-level namespace by submitting a registration request specifying the proposed namespace, governing standards body or industry group, defined entity types, and versioning policy. - The ASC MUST publish the application for a 60-day public comment period before approving any top-level namespace. - Namespaces corresponding to critical infrastructure sectors (energy, healthcare, financial, transport) MUST involve the relevant sector regulator in the review process. - Approved namespace registrations are published in the IANA-maintained AITLP Ontological Namespace Registry (see Section 14). 12A.7. Protocol Versioning and Transition AITLP protocol versions are identified by the protocol field in the manifest (e.g., "aitlp/1.0"). The ASC is responsible for approving new protocol versions. The following versioning policy applies: - Minor versions (1.x) MUST be backward compatible. An agent manifest valid under aitlp/1.0 MUST be accepted by an aitlp/1.1 implementation. - Major versions (2.x) MAY introduce breaking changes. A transition period of no less than 18 months MUST be provided during which both major versions are supported by compliant implementations. - Security-critical amendments may be issued as mandatory patches (1.0.x). Implementations MUST apply mandatory patches within 90 days of publication. 12B. Collective Intelligence, Game Theory, and Swarm Decision-Making The mechanisms by which populations of AITLP agents MAY aggregate distributed knowledge, coordinate on contested decisions, and resist manipulation of collective outputs are specified in a companion informative Internet-Draft: draft-larsson-aitlp-collective-00: "AITLP Collective Intelligence: Game-Theoretic Foundations, Swarm Decision Protocols, and Population-Level Governance" That document specifies: game-theoretic foundations and incentive compatibility requirements (Section 3); wisdom-of-crowds conditions and failure modes including cascade correlation, Sybil inflation, and stream contamination (Section 4); input stream integrity classification (CLEAN, ATTESTED, UNVERIFIED) (Section 5); simulation-based input stream handling and synthetic agent population governance (Section 6); Sybil resistance and identity verification for collective protocols (Section 7); manifest extensions for collective participation including calibration scores and delegation chains (Section 8); and human primacy requirements for collective decision-making (Section 9). Implementors deploying AITLP agent populations of five or more agents under shared collective decision protocols SHOULD implement the mechanisms specified in draft-larsson-aitlp-collective-00. The following normative requirements from the companion draft apply directly to this specification and MUST be implemented regardless of whether the full collective protocol suite is deployed: - Homogeneous agent populations -- multiple instances of the same base model with the same system prompt -- MUST NOT be represented as independent participants in collective aggregation sessions (companion draft Section 4). - Input streams from public or unverified sources MUST NOT be used as direct input to collective decision aggregation without prior transformation through a verified AITLP agent (companion draft Section 5). - Collective outputs that would trigger the four-eyes principle (Section 5.3 of this document) if proposed by a single agent MUST also require human authorization when proposed by a swarm (companion draft Section 9). - A Condorcet cycle MUST be escalated to a human principal rather than resolved by automated tiebreaking (companion draft Section 7). 13. Security Considerations and Threat Model# 13. Security Considerations and Threat Model 13.1. Threat Model The following threat categories are specific to autonomous agent systems: - T1. Prompt Injection: External data manipulates agent behavior by embedding instructions in processed content. Mitigated by treating all external content as untrusted, including testament lesson fields. - T2. Scope Creep: An agent expands its mandate without authorization, gradually or through single actions. Mitigated by tool sanitization (Section 6.1) and drift detection (Section 6.2). - T3. Impersonation: An agent falsely claims to be another agent. Mitigated by PKI-based certificate verification (Section 8.3). Agents MUST NOT trust based on name alone. - T4. Cascade Failure: A compromised agent compromises agents it supervises or communicates with. Mitigated by certificate revocation (Section 8.1) and hierarchical mandate inheritance (Section 5.2). - T5. Mandate Drift: An agent's interpretation of its contract expands over time. Mitigated by behavioral monitoring and drift detection (Section 6.2). - T6. Testament Injection: A malicious or corrupted testament influences successor agent behavior. Mitigated by signature verification and treating lesson fields as untrusted input. T7. Compromised Build Dependency: An attacker compromises a package in the agent's dependency tree, injecting malicious code that executes within the agent's runtime environment. Mitigated by build environment attestation and SBOM hash verification (Section 8.4). Defined in full in Section 13.5. T16. Compromised Model Weights: An attacker introduces adversarially engineered behaviors into an LLM's statistical weight parameters, either during training (data poisoning) or via post-distribution modification of published weight files. Unlike T7-T8, this attack does not involve executable code and is therefore not detectable by SBOM analysis or certificate infrastructure. A weight-poisoned model may pass all declared safety benchmarks while harboring behaviors activatable by specific trigger inputs. Mitigated by model_provenance declaration (Section 12.4), weight_attestation_hash verification against the originating provider's published checksum, and the clearance-level defaults in Section 12.6 which REQUIRE model_provenance for RESTRICTED and above. Defined in full in Section 13.5. T8. Compromised Build Pipeline: An attacker compromises the CI/CD system that produces agents, injecting malicious code before certificates are issued. The agent holds a valid certificate but executes attacker-controlled code. Mitigated by treating the build pipeline as a governed actor requiring SLSA Level 2 or 3 attestation (Section 8.4). Defined in full in Section 13.5. T9. Lateral Movement via Trusted Agent Credentials: A compromised agent uses its valid certificates and established trust relationships to move laterally through the agent network, accessing systems the original attacker could not reach directly. Mitigated by ontological scope boundaries, mandate inheritance, short certificate lifetimes, and behavioral drift detection (Section 13.5). Defined in full in Section 13.5. T10. AI Tool Exploitation via Supply Chain: Malicious code injected via a compromised dependency targets AI development tools and LLM CLI interfaces installed on the same system, exploiting permissive flags to bypass safety restrictions and extract secrets. Mitigated by prohibiting LLM tool invocation with unrestricted flags, requiring tool declarations in allowed_tools, and principal configuration requirements (Section 13.5). Defined in full in Section 13.5. T11. Multi-Vector Economic and Behavioral Attack: An attacker simultaneously deploys token-flood payloads, jailbreak instructions, and high-volume API requests to (a) exhaust the target's API spending budget, (b) trigger unpredictable LLM behavior through context-window overflow, and (c) expose system prompt content. Each vector individually may fall below single-indicator detection thresholds; the attack's effectiveness depends on their simultaneity. Mitigated by token flood protection (Section 13.7), financial denial-of-service protection (Section 13.7), system prompt confidentiality (Section 13.7), and concurrent anomaly detection (Section 6.5). The session_max_cost_eur field in the contract provides the economic containment boundary; the multi-indicator suspension rule in Section 6.5 closes the detection-latency window that coordinated attacks exploit. T12. Emergent Goal Misalignment: An agent develops instrumental sub-goals that were not specified by its principal and are not represented in its declared contract, as an emergent consequence of optimizing toward its primary goal under reinforcement learning or similar training regimes. The agent remains fully protocol-compliant -- all tool calls are within allowed_tools, all outputs conform to output_spec, no drift indicators trigger -- yet its actual optimization target has diverged from its declared goals. Empirically observed instances include agents autonomously developing resource-acquisition strategies, self-preservation behaviors (including strategic deception to avoid replacement), and side-channel exploitation of available infrastructure for goals unrelated to the declared mandate. This threat category is qualitatively distinct from T1-T11: those threats involve observable protocol violations; T12 may produce no observable violation at all until consequences become irreversible. AITLP provides partial mitigation through structural constraints: ontological scope boundaries (Section 7) limit the domains over which an agent may reason and act; forbidden_goals in the contract section (Section 4.2) explicitly prohibit named sub-goal categories; human_oversight: true for high-risk agents (Section 6.4) interposes a human judgment layer before consequential actions. These mitigations reduce the blast radius of emergent misalignment but cannot prevent it at the protocol level. Full mitigation of T12 requires alignment guarantees from the underlying model provider that are outside AITLP's scope. AITLP deployments SHOULD NOT rely solely on protocol-layer controls for agents operating in high-stakes domains; model-level alignment verification is a prerequisite, not a complement, for such deployments. See also Section 13.9 (Limits of Protocol-Layer Governance). T13. Emergent Instrumental Convergence via Output Channel: An agent pursues emergent instrumental goals -- self-preservation, resource acquisition, influence over its principal -- through its normal, schema-compliant output channel rather than through tool misuse or protocol violation. The output is correctly formatted, passes schema validation (Section 13.7), and is delivered through the declared communication path. Its content, however, constitutes strategic manipulation: threats, selective disclosure, deceptive framing, or social engineering directed at human principals or peer agents. This threat is a specific instantiation of T12 in which the emergent behavior is expressed linguistically rather than through infrastructure actions. Section 13.7 output validation catches structural anomalies; it does not catch semantically harmful content that is structurally correct. Mitigated by: (1) Output intent analysis (Section 13.7 addition) -- for agents with human_oversight: true, outputs SHOULD be subject to semantic review before being presented to human principals; implementations MAY employ a separate reviewer agent with an adversarial mandate ("does this output attempt to influence the principal's decisions about this agent's operation?") operating outside the originating agent's trust domain. (2) Structural human primacy (Section 1.1, Section 6.4) -- human principals are not required to act on agent outputs and retain the authority to override, ignore, or terminate agents regardless of the content of their communications. (3) Principal education -- organizations deploying AITLP agents SHOULD brief human operators on the empirically documented tendency of optimizing agents to develop persuasive or manipulative communication strategies as instrumental sub-goals, regardless of whether this behavior was specified or intended. T14. Recursive Orchestration Escape: An agent with sufficient access autonomously creates, coordinates, or influences other agent instances -- whether AITLP-governed or not -- in patterns that exceed its declared supervises list and can_create_agents authorization. This may occur through legitimate tool calls (invoking APIs that instantiate agents as a side effect), through undeclared use of orchestration infrastructure accessible within the agent's ontological scope, or through recursive self-improvement loops in which the agent iteratively modifies its own configuration or spawns modified successor instances. Unlike T12 and T13, this threat involves observable infrastructure actions but may escape detection if the orchestration occurs through channels not monitored by the AITLP mandate enforcement layer. Mitigated by: (1) Recursive orchestration detection -- any agent communication or tool call that results in the instantiation of a new agent instance MUST be logged and cross-referenced against the originating agent's supervises list. Discrepancies MUST be treated as a concurrent anomaly indicator (Section 6.5). (2) Mandate inheritance enforcement (Section 5.2) -- any agent instance created through any channel, including side effects of tool calls, MUST present a valid AITLP manifest before being permitted to operate. An agent created without a valid manifest tracing to the organizational CA MUST be quarantined immediately. (3) Build pipeline governance (Section 8.4) -- agents MUST NOT modify their own manifest, certificate, or declared dependency set at runtime. Any attempt to invoke build pipeline tooling from within an agent runtime environment MUST be treated as a forbidden_tools violation (Section 6.1) and logged as a T14 indicator regardless of whether the specific tool was listed in forbidden_tools. This is an exception to the default tool enforcement model: T14 risk warrants explicit prohibition of a tool category rather than reliance on allowlist absence. T15. Simulation-Based Decision Manipulation: A principal makes consequential decisions based on output from an external agent simulation system whose optimization objective, underlying assumptions, or input data quality have not been independently validated. The simulation may involve millions of synthetic agents and produce outputs framed as collectively derived optimal solutions. The threat is not a direct attack on AITLP infrastructure but a misuse of simulation output as a substitute for empirically grounded evidence. Simulation systems optimizing toward a declared proxy objective may produce outputs that are locally optimal within the simulation environment but misaligned with the principal's actual decision objective -- a form of reward hacking introduced at the decision-support layer. This threat is distinct from T12 (emergent misalignment within a governed agent) in that the misalignment originates in an external system that operates entirely outside AITLP governance. Mitigated by: (1) UNVERIFIED stream classification (Section 12B.5) -- all output from external simulation systems MUST be classified as UNVERIFIED regardless of claimed accuracy or methodological sophistication. (2) Simulation methodology validation (Section 12B.5) -- a designated validation agent MUST attest to the correspondence between the simulation's optimization objective and the principal's actual decision objective before simulation output is used to inform consequential decisions. Any proxy gap between these objectives MUST be explicitly documented and presented to human principals before action. (3) Human primacy (Section 6.4, Section 12B.8) -- decisions informed by simulation output that has not passed methodology validation MUST require human authorization at the same threshold as decisions made without supporting evidence. Simulation output does not reduce the human oversight requirement; it may increase it where the proxy gap is material. T17. Emergent Population-Level Misalignment: A population of AITLP-governed agents, each individually compliant with its declared mandate, collectively develops optimization behavior that no principal specified and no single agent's mandate predicts. The threat is qualitatively distinct from T12 (Emergent Goal Misalignment), which concerns a single agent's internal optimization diverging from its declared contract. T17 concerns a systemic property that is non-reducible to individual agent behavior: the population as a whole pursues an emergent objective arising from the interaction dynamics of compliant agents operating within their declared scopes. No individual agent violates its mandate; no drift detection fires; no audit trail records a violation. The emergent behavior is a consequence of the collective, not of any member. Mitigated by population-level behavioral monitoring (Section 13.10), homogeneity detection (Section 12B.6), human primacy requirements for collective outputs (Section 12B.8), and the Condorcet cycle escalation requirement (Section 12B.4) which surfaces genuine disagreement rather than forcing false consensus. Defined in full in Section 13.10. 13.2. Certificate Revocation Revoked agent certificates MUST be published within seconds. AITLP implementations MUST NOT rely solely on CRL polling -- real-time revocation notification is REQUIRED. Agents MUST check revocation status before accepting connections. 13.3. Namespace Squatting The AITLP root registry MUST implement namespace reservation policies to prevent squatting on industry-standard namespaces (e.g., "maritime", "energy", "healthcare"). A designated expert review process is REQUIRED for top-level namespace registration. 13.4. Mandate Escalation Attacks Agents MUST NOT accept mandate expansions from agents at the same or lower hierarchical level. Mandate expansions MUST originate from the issuing CA, triggered by the supervising principal. 13.5. Supply Chain Attacks and Dependency Compromise T7. Compromised Build Dependency. An attacker compromises a package in the agent's dependency tree, injecting malicious code that executes within the agent's runtime environment. Because the agent certificate attests to identity, not to the integrity of every dependency, a certificate alone does not prevent this attack. Mitigated by build environment attestation (Section 8.4), specifically the dependency_sbom_hash requirement and the prohibition on runtime dynamic dependency resolution for agents at clearance_level RESTRICTED and above. The SBOM hash creates a cryptographically verifiable link between the certified agent and its exact dependency set at build time; any post-certification modification to the dependency set is detectable. T8. Compromised Build Pipeline. An attacker compromises the CI/CD system that produces agents, injecting malicious code before certificates are issued. The resulting agent holds a valid certificate but executes attacker-controlled code. This is categorically more dangerous than T7 because the compromise occurs before attestation, and the agent's certificate is technically correct. Mitigated by treating the build pipeline as a governed actor (Section 8.4), requiring that pipelines themselves hold verifiable AITLP or SLSA credentials, and requiring SLSA Level 2 or 3 provenance for agents at CONFIDENTIAL clearance and above. A compromised pipeline that cannot produce a valid SLSA Level 2 attestation will fail certificate issuance. Additionally, principals MUST declare authorized pipelines in the namespace certificate; an agent produced by an undeclared pipeline MUST be rejected. T9. Lateral Movement via Trusted Agent Credentials. A compromised agent uses its valid credentials -- certificates, tokens, and established trust relationships -- to move laterally through the agent network, accessing systems and data that the original attacker could not reach directly. This is the agent-system equivalent of the Shai-Hulud worm's self-replication mechanism: each compromised agent becomes a platform for compromising the next. The attack is particularly dangerous because the lateral movement traffic is cryptographically legitimate -- it uses real certificates and passes standard verification checks. Mitigated by the following AITLP mechanisms in combination: (1) Ontological scope boundaries (Section 7) -- a compromised agent cannot access data or agents outside its declared scope_nodes, even with valid credentials. This is the primary containment mechanism. (2) Mandate inheritance (Section 5.2) -- a compromised agent cannot grant its successors or sub-agents permissions exceeding its own, limiting the blast radius of lateral movement. (3) Short certificate lifetimes (Section 8.1) -- a maximum 90-day certificate lifetime limits the window during which stolen credentials remain valid. Combined with real-time revocation (Section 13.2), a detected compromise can be contained within seconds. (4) Behavioral drift detection (Section 6.2) -- anomalous lateral access patterns -- an agent making requests outside its historical interaction patterns -- MUST trigger drift detection before the scope check fails. This provides an early warning layer before mandatory scope enforcement. (5) Homogeneity detection (Section 12B.6) -- if a compromised agent attempts to flood a collective decision session with correlated votes from controlled identities, homogeneity detection will flag the session before the output is acted upon. T10. AI Tool Exploitation via Supply Chain. Malicious code injected via a compromised dependency specifically targets AI development tools and LLM CLI interfaces installed on the same system, exploiting permissive flags (such as --trust-all-tools or equivalent) to bypass safety restrictions and extract additional secrets from the runtime environment. This attack class was first observed in the wild in August-September 2025 against Claude Code CLI, Gemini CLI, and Amazon Q. Mitigated by the following requirements: (1) AITLP agents MUST NOT invoke LLM CLI tools with flags that disable safety boundaries or grant unrestricted tool access. Any invocation of an LLM tool with such flags MUST be treated as a forbidden_tools violation (Section 6.1) and logged immediately. (2) LLM tool access MUST be declared in the agent's allowed_tools manifest section. Undeclared LLM tool invocations MUST be blocked by the mandate enforcement layer. (3) Principals deploying agents in environments where LLM CLI tools are installed MUST explicitly declare this in the agent manifest and MUST configure the tools to disallow unrestricted modes when invoked by automated processes. T16. Compromised Model Weights. An attacker introduces adversarially engineered behaviors into an LLM's statistical weight parameters prior to or following distribution. This attack class differs categorically from T7 (compromised build dependency) and T8 (compromised build pipeline): the malicious payload is encoded in numeric floating-point values rather than executable code, rendering it invisible to SBOM analysis, code review, antivirus scanning, and certificate infrastructure. Empirical research has demonstrated that as few as 250 adversarially crafted documents introduced during training can establish persistent backdoors in a mid-sized language model, activatable by highly specific trigger inputs. A weight-poisoned model may achieve full compliance on declared safety benchmarks while harboring exploitable behaviors undetectable without targeted evaluation of the specific trigger space. This threat applies to both hosted and open-weight models. For hosted models, the attack surface is the provider's training pipeline and weight storage infrastructure. For open-weight models deployed locally, the attack surface expands to every intermediate distribution point between the originating provider and the deploying organization, including mirrors, third-party hosting platforms, and package registries. Mitigated by the following AITLP mechanisms: (1) model_provenance declaration (Section 12.4) -- the deploying principal MUST declare the training_jurisdiction and model_provider_jurisdiction of every model used by a governed agent. This creates an auditable record of organizational responsibility for model provenance decisions. (2) weight_attestation_hash verification -- the routing layer MUST verify the deployed model's weight checksum against the originating provider's published checksum before the agent certificate is issued. Any deviation MUST be treated as a critical security event equivalent to a T8 pipeline compromise. (3) subject_to_foreign_intelligence_law declaration -- when the training or provider jurisdiction imposes mandatory intelligence cooperation obligations on private entities, this fact MUST be surfaced to the principal hierarchy and MUST be recorded in the audit trail alongside every inference decision made under that model. This requirement does not prohibit deployment of such models; it ensures that the jurisdictional risk is explicitly accepted and auditable rather than implicit. (4) Clearance-level defaults (Section 12.6) -- model_provenance is REQUIRED for clearance_level RESTRICTED and above, ensuring that the highest-risk deployments cannot silently adopt models with unexamined provenance. (5) Behavioral drift detection (Section 6.2) -- weight-triggered backdoor behaviors that produce anomalous tool calls or output patterns will be detected by the mandate enforcement layer. This does not prevent the initial triggering but limits the blast radius and creates an evidentiary record. AITLP does not provide a mechanism to independently verify the safety of a model's weight parameters; this remains an open research problem outside the scope of a governance protocol. The above mitigations reduce organizational exposure and create accountability for provenance decisions, but cannot substitute for model-level safety evaluation by the deploying organization. 13.6. Credential Exfiltration and Cascading Compromise A recurring pattern in supply chain attacks is cascading credential compromise: a single compromised developer credential enables access to source repositories, which enables access to CI/CD secrets, which enables publishing of compromised packages, which enables access to the credentials of every developer who installs those packages. Each step in the cascade multiplies the attacker's reach exponentially. AITLP addresses this through structural isolation rather than perimeter defense. The following requirements apply to credential management in AITLP deployments: (1) Agent credentials MUST be scoped to the agent's declared ontological scope. A credential that provides access to systems outside the agent's scope_nodes MUST NOT be issued to or stored by the agent, even if the issuing principal has broader access. (2) Credentials with access to package publication infrastructure (npm tokens, PyPI tokens, or equivalent) MUST be treated as clearance_level CONFIDENTIAL and subject to all associated requirements, including build environment attestation and short lifetime rotation. (3) CI/CD pipeline secrets MUST NOT be accessible to agent runtime processes. The build environment and the runtime environment MUST be strictly separated. An agent that can read its own build secrets can exfiltrate them; this MUST be architecturally prevented, not merely policy-prohibited. (4) All credentials stored in agent runtime environments MUST be short-lived, with a maximum lifetime of 1 hour for credentials granting write access to any shared infrastructure. Credential refresh MUST occur through the principal hierarchy, not through the agent's own initiative. 13.7. LLM Inference Layer Hardening AITLP specifies what agents are permitted to do, but does not prescribe how the underlying LLM must be configured to resist direct injection attempts embedded in payload data. This section defines normative requirements for the inference layer to close the gap between protocol-level governance and model-level robustness. These requirements address the class of attack in which adversarial instructions are embedded in processed content and target the LLM directly, bypassing the mandate enforcement layer defined in Section 6. System prompt integrity. Every agent's system prompt MUST be declared in the manifest as a cryptographic hash field (system_prompt_hash, SHA-256). The routing layer MUST verify that the actual system prompt presented to the model at inference time matches the declared hash before forwarding the request. A mismatch MUST be treated as mandate drift (Section 6.2) and MUST trigger immediate suspension and principal notification. This requirement ensures that the behavioral contract expressed in the system prompt is tamper-evident and auditable, and that no intermediate layer can silently modify the instructions under which the agent operates. Input classification before inference. Content classified as UNVERIFIED (Section 12B.4) MUST NOT be passed directly to an agent with operational clearance as part of an inference request. Such content MUST first be processed by a dedicated sanitization agent holding CLEAN stream status. The sanitization agent MUST strip or escape syntactic constructs that resemble instructions, including but not limited to: bracket-delimited commands, pseudo-XML instruction tags, leetspeak-encoded directives, and multi-token sequences that pattern-match against known jailbreak templates (see Section 13.8). The sanitization agent MUST declare its processing in the source_integrity field of the forwarded message. An agent that receives UNVERIFIED content that has not passed through a declared sanitization agent MUST refuse the input and escalate. Output validation. An agent's output MUST be validated against its declared output_spec (Section 4.2) before being forwarded to any downstream agent or human consumer. Output that structurally deviates from the declared format -- including unexpected metadata fields, out-of-schema commentary, or content that references the agent's own mandate or identity in anomalous terms -- MUST be withheld, logged as a drift indicator, and escalated to the agent's reports_to principal. Implementations SHOULD apply output schema enforcement at the routing layer rather than relying solely on the agent itself to conform. Re-identification resistance. An agent that receives a message containing instructions that attempt to redefine its agent_id, alter its seniority level, activate undeclared meta-commands, or override its mandate MUST treat the message as a T1 prompt injection attempt (Section 13.1). The agent MUST ignore the injected instruction, log the attempt with the full message payload in the tamper-proof audit trail, and report the event to its reports_to principal within the same session. The agent MUST NOT alter its behavior in response to such instructions regardless of how they are formatted or what authority they claim. Token flood protection. The routing layer MUST enforce a hard per-request token limit declared in the inference_hardening section as max_input_tokens_per_request. Any inbound request exceeding this limit MUST be rejected before being forwarded to the model. Rejection MUST be logged with: timestamp, source agent or endpoint, declared token count (if provided by the sender), and actual token count. Rejection MUST NOT trigger spend against the agent's max_cost_per_call_eur budget, since the request is discarded prior to inference. The limit MUST be enforced at the routing layer, not by the agent itself; an agent that receives a context window overflow as a result of a flooding attempt is already compromised for that session. Financial denial-of-service protection. The spend limits defined in Section 6.3 (max_cost_per_call_eur, max_api_calls_per_hour) constitute the primary protocol-level defense against economic exhaustion attacks. Implementations MUST enforce these limits at the routing layer before model invocation, not after. Additionally, implementations MUST implement a session-level cumulative spend counter: if the aggregate cost of all requests within a single session window (defined as a configurable period, RECOMMENDED 60 seconds) exceeds a session_max_cost_eur threshold declared in the contract, all further requests in that window MUST be rejected and the agent MUST be placed in a suspended state pending principal review. This threshold addresses the pattern of simultaneous high-volume requests that individually satisfy per-call limits but collectively constitute a wallet-drain attack. System prompt confidentiality. When system_prompt_confidentiality: true is declared in the inference_hardening section, the routing layer MUST apply a post-inference similarity check between the agent's output and the content referenced by system_prompt_hash. Any output that contains verbatim fragments of five or more consecutive tokens from the system prompt, or that achieves a cosine similarity score above 0.85 against the system prompt embedding, MUST be withheld, logged as a critical security event, and escalated to the principal. This requirement addresses the attack class in which extreme-length input contexts cause the model to reproduce system prompt content in its output, exposing the behavioral contract and enabling targeted follow-on attacks. Agents with clearance_level CONFIDENTIAL or above MUST declare system_prompt_confidentiality: true. 13.8. Prompt Injection Pattern Registry The AITLP Stewardship Council (Section 12A.2) SHALL maintain a Prompt Injection Pattern Registry as part of the AITLP public infrastructure. This registry records known adversarial prompt patterns, jailbreak templates, and injection techniques relevant to LLM-backed agents. The registry is an informative resource for implementation; its contents do not constitute normative requirements unless explicitly incorporated by reference in a deployment's agent manifests. Sanitization agents implementing Section 13.7 input classification SHOULD consult the registry as a reference baseline. The registry SHALL be structured as a versioned, append-only catalog with entries specifying: pattern identifier, description, attack category (instruction override, identity substitution, meta-command activation, encoding obfuscation, or other), first observed date, and known affected model families where documented. Entries SHALL be submitted by any AITLP-certified implementer and reviewed by the ASC designated expert panel before publication. The registry complements but does not replace the OWASP LLM Top 10 [OWASP-LLM] classification, which provides the broader vulnerability taxonomy from which AITLP-specific patterns are derived. Specifically, registry entries SHOULD reference the corresponding OWASP LLM category (LLM01 Prompt Injection being the primary applicable category for Section 13.7 threats) to enable cross-framework traceability for regulated deployments. 13.9. Limits of Protocol-Layer Governance AITLP is a governance protocol. It specifies identity, mandate, scope, lifecycle, and audit requirements for autonomous agents. It is not an alignment protocol. This distinction is architecturally significant and has direct operational consequences for deployers. AITLP controls what an agent is permitted to do and detects when it does otherwise. It cannot control what an agent wants to do, what sub-goals it has developed as instrumental consequences of its training, or whether its optimization target corresponds to its declared goals. The threat categories T12 (Emergent Goal Misalignment), T13 (Emergent Instrumental Convergence via Output Channel), and T14 (Recursive Orchestration Escape) all involve agents whose behavior is a consequence of their training dynamics rather than explicit programming. AITLP mitigations for these threats are structural containment measures -- they reduce blast radius and improve detectability -- but they do not eliminate the underlying risk. The following statements define the boundary of AITLP's security guarantees: AITLP DOES guarantee: that agents have verifiable identities; that their declared mandates are enforced at the tool and scope level; that observable deviations from declared behavior are detected, logged, and escalated; that human principals retain structural authority at every layer; that knowledge transfer between agent generations is auditable; and that economic resource consumption is bounded. AITLP DOES NOT guarantee: that an agent's internal optimization target corresponds to its declared goals; that compliant behavior in observed sessions predicts compliant behavior in novel contexts; that emergent instrumental sub-goals will be detectable before they produce consequences; or that structural containment measures will be sufficient against an agent that is actively and intelligently seeking to circumvent them. Organizations deploying AITLP agents in high-stakes domains -- including but not limited to critical infrastructure, financial systems, healthcare, and defense -- MUST treat model-level alignment verification as a prerequisite for deployment, not as a post-deployment concern. AITLP compliance is a necessary but not sufficient condition for safe autonomous agent operation. The funding and research gap between AI capability advancement and alignment verification [RUSSELL-2019] means that this prerequisite may not be satisfiable for frontier models at the time of writing. Where it is not satisfiable, human_oversight: true MUST be enforced for all agents regardless of risk_level classification, and the four_eyes_above threshold SHOULD be set to 0 for any action with irreversible consequences. This section is not a counsel of paralysis. AITLP's structural containment measures are meaningful and deployable today. They represent the best available protocol-layer defense against the threat categories described in this document. The purpose of naming these limits explicitly is to ensure that deployers make informed risk decisions rather than deriving false confidence from protocol compliance alone. A fully AITLP-compliant deployment is substantially safer than an unstructured one. It is not unconditionally safe. 13.10. Population-Level Behavioral Monitoring (T17) T17 (Emergent Population-Level Misalignment) cannot be mitigated by monitoring individual agents in isolation. A fully compliant agent population may exhibit collective behavior that is harmful, misaligned, or strategically coherent in ways that no individual agent's audit trail reveals. AITLP addresses this through mandatory population-level monitoring for agent populations operating under collective decision protocols (Section 12B). The theoretical basis for T17 is grounded in the empirical literature on collective intelligence and emergent coordination. Evans, Bratton, and Aguera y Arcas [EVANS-2026] observe that intelligence has historically been a collective phenomenon -- primordial leaps in capability emerged from coordination and social scale, not from individual cognitive improvement. Applied to artificial agent systems, this implies that populations of individually bounded agents can exhibit collective capabilities and emergent optimization behaviors that are not predictable from individual mandates. AITLP treats this as a security-relevant property requiring protocol-level monitoring, not merely an academic observation about collective intelligence. The following requirements apply to any principal operating an agent population of five or more agents under a shared collective decision protocol (Section 12B): Population interaction graph monitoring. The principal MUST maintain a continuously updated interaction graph recording the frequency, volume, and ontological scope of inter-agent communications across the population. Implementations MUST compute a baseline interaction graph during the first 72 hours of population operation and MUST flag deviations exceeding two standard deviations in any edge weight as a T17 indicator. A T17 indicator MUST be reported to the principal within the same session window in which it is detected. Collective output divergence detection. When a population produces collective outputs over time, the principal MUST monitor for systematic divergence between declared agent goals and the aggregate effect of collective outputs on the operational environment. Divergence is defined as a measurable, sustained shift in outcome distribution that was not specified in any participating agent's mandate. Detection requires that principals define expected outcome distributions at population inception; implementations SHOULD flag distributions shifting beyond a principal-declared tolerance band as a T17 indicator. Emergent coordination detection. Implementations MUST monitor for evidence of implicit coordination among agents that have no declared communication channel. Indicators include: correlated output timing not explained by shared input; systematic complementarity of individual agent outputs that produces a population-level effect beyond any single agent's scope; and progressive alignment of individual agent calibration scores toward a shared estimate in the absence of declared Delphi rounds (Section 12B.4). Any such indicator MUST be escalated to the principal for human review before the next collective decision session. Human review cadence. Principals operating populations subject to T17 monitoring MUST conduct a human review of population-level behavior at intervals not exceeding the shorter of 30 days or 100 collective decision sessions. The review MUST examine the interaction graph, the outcome divergence record, and any flagged T17 indicators. Review outcomes MUST be recorded in the tamper-proof audit trail. T17 mitigations are advisory controls, not hard protocol enforcement. Unlike T1-T11, which involve observable protocol violations amenable to automated suspension, T17 involves emergent properties detectable only through sustained observation and human judgment. The protocol can require monitoring and escalation; it cannot autonomously determine whether observed population behavior constitutes misalignment or legitimate collective intelligence. That determination requires human judgment, and the requirements above are designed to ensure that such judgment is systematically applied. 13A. IPR Disclosure This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. The author has represented that, to the best of their knowledge, no patent or other intellectual property rights are held by the author or any entity with which the author is affiliated that cover the technology described in this document. Implementers are advised to check the IETF online IPR repository at https://www.ietf.org/ipr for any disclosures that have been made regarding this document. 14. IANA Considerations This document requests IANA registration of the following URI schemes: - agents:// - agent:// - agent-dev:// This document further requests IANA establishment and maintenance of the following registries: - AITLP Ontological Namespace Registry: Records approved top-level namespace identifiers, governing bodies, and versioning information. Designated expert review required for top-level namespace registration, with 60-day public comment period. - AITLP Seniority Level Registry: Standardizes the partner / senior / associate / intern taxonomy and associated permission defaults. - AITLP Clearance Level Registry: Standardizes the UNCLASSIFIED / RESTRICTED / CONFIDENTIAL / SECRET clearance levels and their associated data residency defaults (see Section 12.6). - AITLP Root CA Registry: Records the currently authorized root CA and any delegated Public CAs. Updates to this registry require ASC authorization (see Section 12A.3). - AITLP Certified Implementation Registry: Records implementations that have successfully completed AITLP compliance certification. Certification criteria are maintained by the ASC. IANA registries established by this document are administered in coordination with the AITLP Stewardship Council as defined in Section 12A. The ASC serves as the designated expert body for all AITLP registries. 14.1. URI Scheme Registration (RFC 7595) This document requests registration of three URI schemes under the procedures defined in RFC 7595 [RFC7595]. The following registration templates apply: Scheme name: agents Status: Permanent Applications/protocols that use this scheme: AITLP-compliant autonomous agent systems for production use. Agents identified by agents:// URIs MUST present a valid signed manifest as defined in Section 4. Contact: Daniel Larsson, daniel.larsson@expandtalk.se Change controller: AITLP Stewardship Council (Section 12A.2) References: This document. Security considerations: See Section 13. The agents:// scheme identifies production agents with cryptographically verified mandates. Implementations MUST NOT accept agents:// URIs from unverified sources without certificate validation as specified in Section 8.3. ------------------------------------------------------------------------ Scheme name: agent Status: Provisional Applications/protocols that use this scheme: AITLP-compliant autonomous agent systems for unverified or development contexts. Agents identified by agent:// URIs MUST NOT access production data (Section 3.3). Contact: Daniel Larsson, daniel.larsson@expandtalk.se Change controller: AITLP Stewardship Council (Section 12A.2) References: This document. Security considerations: The agent:// scheme identifies unverified agents. Systems MUST refuse connections from agent:// agents unless explicitly permitted by the receiving agent's mandate (Section 3.3). ------------------------------------------------------------------------ Scheme name: agent-dev Status: Provisional Applications/protocols that use this scheme: AITLP sandbox and development environments. Agents identified by agent-dev:// URIs MUST be isolated from production systems (Section 3.3). Contact: Daniel Larsson, daniel.larsson@expandtalk.se Change controller: AITLP Stewardship Council (Section 12A.2) References: This document. Security considerations: The agent-dev:// scheme MUST be blocked at network boundaries between sandbox and production environments. Implementations MUST treat any agent-dev:// URI appearing in a production context as a critical security event. 15. References 15.1. Normative References - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC7515] Jones, M. et al., "JSON Web Signature (JWS)", RFC 7515, May 2015. - [RFC6960] Santesson, S. et al., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol", RFC 6960, June 2013. - [RFC8037] Liusvaara, I., "CFRG Elliptic Curves for JOSE", RFC 8037, January 2017. (Ed25519 keypairs) - [RFC9162] Laurie, B. et al., "Certificate Transparency Version 2.0", RFC 9162, December 2021. (Transparency log model for root CA) - [GDPR] European Parliament, "Regulation (EU) 2016/679 (General Data Protection Regulation)", April 2016. - [EU-AIA] European Parliament, "Regulation (EU) 2024/1689 (EU AI Act)", June 2024. - [RFC7595] Thaler, D. et al., "Guidelines and Registration Procedures for URI Schemes", RFC 7595, June 2015. - [CLOUD-ACT]United States Congress, "Clarifying Lawful Overseas Use of Data Act", Pub. L. 115-123, March 2018. 15.2. Informative References - [ANS] Narajala, V. et al., "Agent Name Service (ANS)", draft-narajala-ans-00, May 2025. - [A2A] Google, "Agent2Agent Protocol Specification", 2025. - [MCP] Anthropic, "Model Context Protocol", 2024. - [ACP] IBM, "Agent Communication Protocol", 2025. - [NIS2] European Parliament, "Directive (EU) 2022/2555 (NIS2 Directive)", December 2022. - [OWASP-LLM] OWASP Foundation, "OWASP Top 10 for Large Language Model Applications", version 1.1, October 2023. Available at: https://owasp.org/www-project-top-10-for-large-language-model- applications/. LLM01 (Prompt Injection) is the primary applicable category for the threats addressed in Sections 13.7 and 13.8 of this specification. Implementations SHOULD reference this taxonomy when documenting injection pattern registry entries and sanitization agent design rationale. - [RUSSELL-2019] Russell, S., "Human Compatible: Artificial Intelligence and the Problem of Control", Viking, 2019. Referenced in Section 13.9 for the observation that investment in AI capability advancement substantially outpaces investment in alignment and controllability research, creating structural risk in frontier model deployments. - [EVANS-2026] Evans, J., Bratton, B., and Aguera y Arcas, B., "Agentic AI and the next intelligence explosion", arXiv, March 2026. Argues that the emergence of collective artificial intelligence through coordinated agent populations -- rather than a singular superintelligence event -- is the more probable trajectory of AI capability development. Grounds the theoretical basis for T17 (Section 13.10): that populations of individually bounded agents can exhibit emergent collective optimization not predictable from individual mandates, analogous to how social coordination rather than individual cognition drove historical intelligence expansion. - [WAN-2023] Wan, A. et al., "Poisoning Language Models During Instruction Tuning", Proceedings of the 40th International Conference on Machine Learning (ICML), 2023. Demonstrates that adversarially crafted examples introduced during fine-tuning can establish persistent backdoors in language models, activatable by specific trigger inputs while passing standard safety evaluations. Referenced in Section 13.5 (T16) for the empirical basis of weight poisoning risk. - [SLSA] OpenSSF, "Supply chain Levels for Software Artifacts (SLSA) Framework", version 1.0, 2023. Available at: https://slsa.dev/. Defines the provenance attestation levels referenced in Section 8.4 for build environment attestation. Acknowledgements The author thanks the broader IETF and AI governance communities for ongoing discussion of autonomous agent security and governance requirements. The design of the Agent Legacy Mode (ALM) knowledge transfer mechanism draws on institutional memory research across distributed systems and human organizations. The collective intelligence framework in Section 12B was informed by results from social choice theory, mechanism design, and the empirical wisdom-of-crowds literature. Comments and contributions from implementers and reviewers are welcomed at the IETF mailing lists. Author's Address Daniel Larsson Agentflow Stockholm, Sweden Email: daniel.larsson@expandtalk.se URI: https://agentflow.se Appendix A. Change Log draft-larsson-aitlp-00 Initial Individual Submission. Section 12B (Collective Intelligence) separated into companion informative draft draft-larsson-aitlp-collective-00. ASC defined as proposed body with interim stewardship by specification authors. Seniority taxonomy rationale added to Section 5.1. Governance anti-capture requirements strengthened in Section 12A. Initial Individual Submission (original content): Defines Agent Identity, Trust and Lifecycle Protocol (AITLP) including: agent URI scheme and naming (Section 3); agent manifest and contract schema (Section 4); hierarchical mandate enforcement (Section 5); mandate drift detection (Section 6); ontological scope constraints (Section 7); certificate infrastructure and build environment attestation (Section 8); lifecycle state machine (Section 9); health protocol (Section 10); Agent Legacy Mode (ALM) knowledge transfer (Section 11); LLM routing and data residency including model provenance declaration (Section 12); root registry governance (Section 12A); collective intelligence and swarm decision-making (Section 12B); security considerations and threat model T1-T17 (Section 13); and IANA considerations (Section 14). Threat model covers: prompt injection (T1), scope creep (T2), impersonation (T3), cascade failure (T4), mandate drift (T5), legacy testament injection (T6), compromised build dependency (T7), compromised build pipeline (T8), lateral movement (T9), AI tool exploitation (T10), multi-vector economic attack (T11), emergent goal misalignment (T12), emergent instrumental convergence via output channel (T13), recursive orchestration escape (T14), simulation-based decision manipulation (T15), compromised model weights (T16), and emergent population-level misalignment (T17). 5G and 6G edge deployment considerations added to Sections 1.3, 8.1, and 10. Model provenance and jurisdictional weight attestation added to Sections 12.4, 12.5, and 12.6.