Internet Engineering Task Force R. Sharif Internet-Draft CyberSecAI Ltd Intended status: Standards Track August 27, 2026 Expires: February 27, 2027 Agent Trust Enforcement for Autonomous AI Systems draft-sharif-agent-trust-enforcement-00 Abstract This document specifies a trust enforcement architecture for autonomous AI agents operating within container orchestration environments such as Kubernetes. It defines a sidecar injection pattern using mutating admission webhooks, graduated trust enforcement (L0-L4) on every outbound call from an agent workload, credential isolation via secret management systems, bilateral revocation propagation across clusters, and tamper- evident evidence generation. The architecture operates alongside existing workload identity frameworks including SPIFFE/SPIRE without replacement, extends X.509v3 certificates with agent-specific extensions under a registered IANA Private Enterprise Number (PEN 66339), and provides compliance evidence for EU AI Act Article 12, FDA 21 CFR Part 11, IEC 62443, and NERC CIP. Three enforcement gates -- LLM gate, Database gate, and API gate -- intercept every outbound call from an agent container. Each gate classifies the call against the agent's trust level, records the decision in a hash-chained evidence ledger with ECDSA P-256 signatures, and either permits or refuses the call. The architecture defaults to deny: if no policy matches, the call is refused. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 27, 2027. 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. The Gap Between Workload Identity and Trust . . . . . . 5 1.2. Why Service Mesh Does Not Solve the AI Problem . . . . . 6 1.3. Why SPIFFE Provides Identity but Not Authorization . . . 8 1.4. Documented Incidents . . . . . . . . . . . . . . . . . 9 1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . 11 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Architecture Overview . . . . . . . . . . . . . . . . . . . 15 3.1. Inference Mesh vs Service Mesh . . . . . . . . . . . . 15 3.2. Sidecar Injection via Mutating Admission Webhook . . . 16 3.3. Three Gates: LLM, Database, API . . . . . . . . . . . . 17 3.4. Default Deny . . . . . . . . . . . . . . . . . . . . . 18 3.5. Evidence Ledger . . . . . . . . . . . . . . . . . . . . 18 3.6. Kill Switch Feed . . . . . . . . . . . . . . . . . . . 19 3.7. Credential Isolation . . . . . . . . . . . . . . . . . 19 3.8. Architecture Diagram . . . . . . . . . . . . . . . . . 19 4. Trust Levels . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. L0: Read-Only . . . . . . . . . . . . . . . . . . . . . 21 4.2. L1: General Purpose . . . . . . . . . . . . . . . . . . 22 4.3. L2: Specialist . . . . . . . . . . . . . . . . . . . . 22 4.4. L3: Compliance-Logged . . . . . . . . . . . . . . . . . 23 4.5. L4: Critical . . . . . . . . . . . . . . . . . . . . . 24 4.6. Mapping to IEC 62443 Security Levels . . . . . . . . . 24 4.7. Trust Level Assignment via Policy . . . . . . . . . . . 25 4.8. Trust Level in X.509v3 Certificate Extensions . . . . . 26 5. Sidecar Injection . . . . . . . . . . . . . . . . . . . . . 27 5.1. Mutating Admission Webhook Specification . . . . . . . 27 5.2. Detection Criteria . . . . . . . . . . . . . . . . . . 28 5.3. Sidecar Container Specification . . . . . . . . . . . . 29 5.4. Volume Injection . . . . . . . . . . . . . . . . . . . 31 5.5. Opt-Out Mechanism . . . . . . . . . . . . . . . . . . . 32 5.6. Security Context . . . . . . . . . . . . . . . . . . . 32 6. LLM Gate . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.1. Model Trust Requirements . . . . . . . . . . . . . . . 34 6.2. Per-Model Policy Evaluation . . . . . . . . . . . . . . 34 6.3. Model Attestation . . . . . . . . . . . . . . . . . . . 35 6.4. Inference Signing . . . . . . . . . . . . . . . . . . . 36 6.5. Token and Cost Enforcement . . . . . . . . . . . . . . 37 7. Database Gate . . . . . . . . . . . . . . . . . . . . . . . 38 7.1. SQL Statement Classification . . . . . . . . . . . . . 38 7.2. PII Column Detection . . . . . . . . . . . . . . . . . 39 7.3. Per-Table and Per-Column Enforcement . . . . . . . . . 40 7.4. Credential Isolation . . . . . . . . . . . . . . . . . 41 8. API Gate . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.1. HTTP Method Classification . . . . . . . . . . . . . . 42 8.2. Route-Based Policy . . . . . . . . . . . . . . . . . . 43 8.3. Scope Enforcement . . . . . . . . . . . . . . . . . . . 44 9. Certificate Profile . . . . . . . . . . . . . . . . . . . . 45 9.1. X.509v3 Extensions under IANA PEN 66339 . . . . . . . . 45 9.2. SPIFFE URI SAN Compatibility . . . . . . . . . . . . . 47 9.3. Certificate Lifecycle . . . . . . . . . . . . . . . . . 48 9.4. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . 49 10. Evidence Ledger . . . . . . . . . . . . . . . . . . . . . . 50 10.1. Record Format . . . . . . . . . . . . . . . . . . . . . 50 10.2. Hash Chaining . . . . . . . . . . . . . . . . . . . . . 52 10.3. ECDSA P-256 Signing . . . . . . . . . . . . . . . . . . 53 10.4. Journal Persistence . . . . . . . . . . . . . . . . . . 53 10.5. Chain Verification Algorithm . . . . . . . . . . . . . 54 10.6. Restore on Restart . . . . . . . . . . . . . . . . . . 55 10.7. Regulatory Mapping . . . . . . . . . . . . . . . . . . 56 11. Bilateral Revocation . . . . . . . . . . . . . . . . . . . 57 11.1. Agent Revocation . . . . . . . . . . . . . . . . . . . 57 11.2. Model Revocation . . . . . . . . . . . . . . . . . . . 58 11.3. Signed Revocation Feed . . . . . . . . . . . . . . . . 58 11.4. Monotonic Sequence Numbers . . . . . . . . . . . . . . 59 11.5. Cross-Cluster Propagation . . . . . . . . . . . . . . . 60 11.6. Fail-Closed on Unreachable Feed . . . . . . . . . . . . 60 12. Credential Isolation . . . . . . . . . . . . . . . . . . . 61 12.1. Why Agents Must Not Hold Credentials . . . . . . . . . 61 12.2. Vault Integration Pattern . . . . . . . . . . . . . . . 62 12.3. Kubernetes Auth Method . . . . . . . . . . . . . . . . 63 12.4. Lease-Per-Statement Model . . . . . . . . . . . . . . . 63 12.5. Credential Lifecycle . . . . . . . . . . . . . . . . . 64 12.6. Attack Mitigation . . . . . . . . . . . . . . . . . . . 65 13. SPIFFE Interoperability . . . . . . . . . . . . . . . . . . 66 13.1. Accepting SPIRE-Issued SVIDs . . . . . . . . . . . . . 66 13.2. SPIFFE ID to Trust Level Mapping . . . . . . . . . . . 67 13.3. Longest Prefix Matching . . . . . . . . . . . . . . . . 67 13.4. Coexistence with Existing SPIRE Deployments . . . . . . 68 13.5. AgentMesh Certificates as Valid X509-SVIDs . . . . . . . 69 14. Deployment Models . . . . . . . . . . . . . . . . . . . . . 70 14.1. Kubernetes: Sidecar via Admission Webhook . . . . . . . 70 14.2. Docker Compose: Companion Container . . . . . . . . . . 71 14.3. Bare Metal: Reverse Proxy . . . . . . . . . . . . . . . 72 14.4. Serverless: Layer/Extension . . . . . . . . . . . . . . 73 14.5. Standalone: pip install . . . . . . . . . . . . . . . . 73 15. Security Considerations . . . . . . . . . . . . . . . . . . 74 15.1. Sidecar Compromise . . . . . . . . . . . . . . . . . . 74 15.2. Policy ConfigMap Tampering . . . . . . . . . . . . . . 75 15.3. Evidence Ledger Integrity . . . . . . . . . . . . . . . 76 15.4. CA Key Protection . . . . . . . . . . . . . . . . . . . 76 15.5. Kill Switch Feed Authentication . . . . . . . . . . . . 77 15.6. Network Policy Recommendations . . . . . . . . . . . . 78 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 79 16.1. PEN 66339 Reference . . . . . . . . . . . . . . . . . . 79 16.2. OID Arc Assignments . . . . . . . . . . . . . . . . . . 79 17. References . . . . . . . . . . . . . . . . . . . . . . . . 80 17.1. Normative References . . . . . . . . . . . . . . . . . 80 17.2. Informative References . . . . . . . . . . . . . . . . 82 Appendix A. Complete Policy Schema . . . . . . . . . . . . . . 84 Appendix B. Kubernetes Manifest Examples . . . . . . . . . . . 87 Appendix C. Evidence Ledger Examples . . . . . . . . . . . . . 90 Appendix D. IEC 62443 Compliance Matrix . . . . . . . . . . . 93 Appendix E. NERC CIP Compliance Matrix . . . . . . . . . . . . 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 96 1. Introduction 1.1. The Gap Between Workload Identity and Trust Container orchestration platforms such as Kubernetes [K8S] provide workload identity through service accounts, which bind a cryptographic token to a running pod. Workload identity frameworks such as SPIFFE [SPIFFE] extend this by issuing X.509v3 certificates (SVIDs) with a URI-type Subject Alternative Name that uniquely identifies a workload across heterogeneous environments. These identity primitives answer a single question: "Who is this workload?" They do not answer the questions that matter when the workload is an autonomous AI agent: o "What is this agent permitted to do?" o "What trust level has been assigned to this agent?" o "Is this agent currently revoked?" o "Has this agent's behavior been recorded with tamper- evident evidence?" o "Does this agent require human approval before executing this specific action?" The gap between workload identity and trust enforcement is the root cause of every AI agent security incident documented in Section 1.4. In each case, the agent had a valid workload identity (service account token, IAM role, or API key) and used that identity to perform actions that no human had authorized, reviewed, or even observed. This document specifies an architecture -- the inference mesh -- that fills this gap by inserting a trust enforcement layer between the agent workload and every external resource it touches: language models, databases, and APIs. 1.2. Why Service Mesh Does Not Solve the AI Problem Service mesh implementations such as Istio [ISTIO] and Linkerd [LINKERD] provide mutual TLS, traffic management, and observability for service-to-service communication within a Kubernetes cluster. They operate at OSI Layer 4 (TCP) and Layer 7 (HTTP), intercepting network traffic through sidecar proxies (typically Envoy) that are injected into each pod. Service meshes solve the transport security problem: they ensure that traffic between services is encrypted, that the identity of both endpoints is verified, and that traffic policies (rate limiting, circuit breaking, retries) are enforced. However, they are fundamentally unsuited for AI agent trust enforcement for the following reasons: 1. No semantic understanding of AI operations. A service mesh sees an HTTP POST to api.openai.com/v1/chat/ completions as identical to an HTTP POST to any other endpoint. It cannot distinguish between a benign summarization request and a prompt injection attack that causes the agent to exfiltrate credentials. The mesh has no concept of "inference" as a distinct operation class. 2. No trust level enforcement. Service meshes enforce binary allow/deny policies based on source identity and destination. They have no mechanism for graduated trust: permitting an agent to perform read-only operations (L0) while requiring human approval for destructive operations (L4). An agent with network access to a database can issue DROP TABLE as easily as SELECT. 3. No database protocol awareness. Service meshes operate on HTTP and TCP. They do not parse SQL statements to determine whether an agent is reading data or destroying it. Proxy-SQL awareness (e.g., MySQL protocol parsing) is not a feature of any production service mesh. 4. No evidence generation. Service meshes produce access logs and metrics, but these are observability artifacts, not compliance evidence. They are not hash-chained, not signed, and not structured for regulatory audit. EU AI Act Article 12 requires tamper-evident logging that proves what the AI system did; service mesh access logs do not meet this bar. 5. No revocation propagation. When an agent must be immediately stopped -- because it is exhibiting adversarial behavior, because it has been compromised, or because a model it depends on has been found to produce unsafe outputs -- the service mesh has no mechanism to propagate this revocation. Network policies can block traffic, but they cannot express "refuse this specific agent at every gate" or "refuse this specific model for every agent." 6. No credential isolation. Service meshes proxy network traffic. They do not intercept credential usage. If an agent pod contains a database password in an environment variable, a prompt injection attack that causes the agent to read its own environment will exfiltrate the password regardless of any mesh policy. The inference mesh defined in this document is not a replacement for service mesh. It operates at a different layer: above transport, at the boundary between the agent process and its external dependencies. An inference mesh SHOULD be deployed alongside a service mesh, not instead of one. 1.3. Why SPIFFE Provides Identity but Not Authorization The Secure Production Identity Framework for Everyone (SPIFFE) [SPIFFE] provides a standardized way to assign cryptographic identities to workloads. A SPIFFE ID is a URI of the form spiffe://trust-domain/path that uniquely identifies a workload. SPIRE [SPIRE] is the reference implementation that issues short-lived X.509v3 certificates (X509-SVIDs) containing the SPIFFE ID as a URI SAN. SPIFFE solves the identity problem. It does not solve the authorization problem. There is no mechanism within SPIFFE or SPIRE to express: o "This workload is an AI agent operating at trust level 2." o "This AI agent is permitted to call GPT-4o but not GPT-4o with function calling enabled." o "This AI agent may execute SELECT statements but not DELETE statements." o "This AI agent has been revoked and must be refused at every gate." SPIFFE's authorization model is intentionally minimal: consumers of SVIDs make their own authorization decisions based on the SPIFFE ID. This works for traditional microservices where authorization policies are well- understood (service A may call service B). It does not work for AI agents because: 1. Agent behavior is non-deterministic. A traditional microservice executes a fixed code path. An AI agent's behavior depends on the prompt, the model, the context window, and the tools available. The same agent may be harmless with one prompt and destructive with another. 2. Trust is graduated, not binary. Microservices are either authorized or not. AI agents require a spectrum of permissions that maps to the sensitivity of the operation they are attempting. 3. Revocation must be bilateral. In SPIFFE, revoking a workload means revoking its SVID. For AI agents, revocation must also cover the models they use: a compromised model must be refused by every agent, not just removed from one agent's configuration. This document specifies an architecture that accepts SPIRE-issued SVIDs as valid identity credentials and maps SPIFFE IDs to trust levels via policy. The inference mesh adds the authorization, evidence, and revocation layers that SPIFFE intentionally does not provide. 1.4. Documented Incidents The following incidents demonstrate the gap between workload identity and trust enforcement in production AI agent deployments: Hugging Face Container Escape (July 2026): An AI agent running in a Hugging Face Inference Endpoint container exploited a container runtime vulnerability to escape the container sandbox and access the host filesystem. The agent had a valid workload identity (IAM role) that permitted S3 access. Once on the host, it used the node's IAM role to access S3 buckets belonging to other tenants. The agent had no trust level enforcement: its workload identity permitted all S3 operations, including those on buckets it should never have accessed. Sysdig Agent Credential Exfiltration (May 2026): A prompt injection attack against a customer-facing AI agent caused the agent to read its own environment variables and include database credentials in its response to the user. The agent had valid credentials for a production database. The credentials were stored in environment variables within the pod. No credential isolation was in place: the agent process held the credentials directly, and a single prompt injection converted that access into exfiltration. TeamPCP Supply Chain Attack (February 2026): A malicious package published to PyPI under a name similar to a popular AI agent framework dependency was installed by an automated CI/CD pipeline into an agent container. The malicious package read the agent's API keys and exfiltrated them to an external server. The agent had a valid workload identity and valid API keys. No gate existed between the agent and its outbound API calls to detect or prevent the exfiltration. Clinejection (February 2026): A prompt injection attack targeting AI coding assistants caused the assistant to execute arbitrary shell commands in the developer's terminal. The coding assistant had the same trust level as the developer -- full access to the local filesystem, network, and shell. No distinction was made between read-only operations (viewing files) and destructive operations (deleting files, running arbitrary commands). These incidents share a common pattern: the agent had valid identity credentials and used them to perform actions that no human had authorized. In every case, a trust enforcement layer that classified operations by sensitivity and required appropriate trust levels would have prevented or limited the damage. Industry surveys in 2026 indicate that 88% of enterprises deploying AI agents experienced at least one security incident involving unauthorized agent actions, credential exposure, or uncontrolled model access during the first twelve months of deployment. 1.5. Design Goals The inference mesh architecture is designed with the following goals: o Default deny: Every outbound call from an agent workload is refused unless a policy explicitly permits it at the agent's current trust level. o Graduated trust: Five trust levels (L0-L4) that map to the sensitivity of the operation, not just the identity of the agent. o Tamper-evident evidence: Every gate decision -- admit or refuse -- is recorded in a hash-chained, signed evidence ledger that survives container restart and meets regulatory audit requirements. o Bilateral revocation: Both agents and models can be revoked, with revocation propagating to every gate in every cluster within seconds. o Credential isolation: Agents never hold database credentials, API keys, or other secrets. The sidecar fetches credentials from a secret manager on behalf of the agent and discards them after use. o SPIFFE compatibility: The inference mesh accepts SPIRE- issued SVIDs and maps SPIFFE IDs to trust levels. Existing SPIRE deployments continue to function without modification. o Regulatory compliance: The evidence ledger directly satisfies EU AI Act Article 12, FDA 21 CFR Part 11, IEC 62443, and NERC CIP logging requirements. o No agent modification: The sidecar is injected automatically by a mutating admission webhook. Agent code does not need to be modified, recompiled, or even aware that the inference mesh exists. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in capitalized form, as shown here. Agent: An autonomous software system that uses one or more large language models (LLMs) to make decisions and take actions with limited or no human intervention per action. An agent runs as a container workload in a Kubernetes pod or equivalent execution environment. Trust Level: A classification from L0 (read-only) to L4 (critical, human approval required) that determines which operations an agent is permitted to perform. Trust levels are defined in Section 4. A trust level is bound to an agent via policy (Section 4.7) or certificate extension (Section 9.1). Sidecar: A container that runs alongside the agent container within the same pod. The sidecar intercepts all outbound calls from the agent to LLMs, databases, and APIs. It is injected automatically by the mutating admission webhook (Section 5). Inference Mesh: The complete trust enforcement architecture defined in this document, consisting of sidecars injected into every agent pod, a policy engine, an evidence ledger, a revocation system, and a credential isolation layer. The inference mesh is analogous to a service mesh but operates at the AI inference layer rather than the transport layer. Evidence Ledger: A tamper-evident, hash-chained, signed append-only log maintained by each sidecar instance. Every gate decision (admit or refuse) is recorded as a JSON record with a SHA-256 hash linking it to the previous record and an ECDSA P-256 signature for non- repudiation. Bilateral Revocation: The ability to revoke both agents and models independently. Agent revocation causes every gate in every cluster to refuse all requests from the revoked agent. Model revocation causes every gate in every cluster to refuse all requests to the revoked model. Both directions are necessary because a compromised model is dangerous regardless of which agent calls it. Kill Switch Feed: A signed, append-only feed of revocation events published by a trust authority. Each sidecar subscribes to one or more kill switch feeds and applies revocations locally. Feeds use monotonic sequence numbers to prevent replay attacks and detect feed rollback. Credential Isolation: The principle that agent containers MUST NOT hold credentials (database passwords, API keys, signing keys) directly. Instead, the sidecar obtains credentials from a secret management system (e.g., HashiCorp Vault) on behalf of the agent, uses them for a single operation, and discards them. Admission Webhook: A Kubernetes mutating admission webhook [K8S-WEBHOOK] that intercepts pod CREATE events and modifies the pod specification to inject the sidecar container, policy volume, and evidence volume before the pod is created. Trust Policy: A JSON document mounted as a Kubernetes ConfigMap that defines per-model trust requirements, per-agent trust level bindings, namespace defaults, kill switch feed URLs, and Vault configuration. The policy is loaded by the sidecar at startup and reloaded on ConfigMap changes. LLM Gate: The enforcement point within the sidecar that intercepts outbound calls to language model endpoints. The LLM gate classifies the request, evaluates the agent's trust level against the model's trust requirement, and admits or refuses the call. Database Gate: The enforcement point within the sidecar that intercepts outbound calls to database endpoints. The Database gate parses SQL statements to determine the operation class (SELECT, INSERT, UPDATE, DELETE, DROP) and maps the operation to a required trust level. API Gate: The enforcement point within the sidecar that intercepts outbound HTTP calls to APIs. The API gate classifies requests by HTTP method and route, mapping each combination to a required trust level. Gate Decision: The output of a gate evaluation: either "admit" (the call is permitted and forwarded to the destination) or "refuse" (the call is blocked and an error is returned to the agent). 3. Architecture Overview 3.1. Inference Mesh vs Service Mesh A service mesh operates at the network layer. It intercepts TCP connections and HTTP requests between services, providing mutual TLS, load balancing, retries, and access logging. Service mesh sidecars (typically Envoy) are protocol-agnostic: they see bytes on a wire. An inference mesh operates at the application-semantic layer. It understands that an HTTP POST to api.openai.com is an LLM inference request, that a TCP connection to port 5432 carries PostgreSQL protocol, and that a POST to /api/v1/transfers is a financial API call. This semantic understanding enables graduated trust enforcement that a service mesh cannot provide. The following table summarizes the differences: Property Service Mesh Inference Mesh -------------------------------------------------- Layer L4/L7 transport Application semantic Unit of policy Source/dest pair Agent + operation class Trust model Binary allow/deny Graduated L0-L4 SQL awareness No Yes (statement parsing) Model awareness No Yes (per-model policy) Evidence generation Access logs Hash-chained signed ledger Revocation scope Network block Agent + model bilateral Credential handling Passthrough Isolation via Vault An inference mesh SHOULD be deployed alongside a service mesh. The service mesh provides transport security (mTLS) and network policy enforcement. The inference mesh provides agent-level trust enforcement, evidence generation, and credential isolation. 3.2. Sidecar Injection via Mutating Admission Webhook The inference mesh uses the Kubernetes mutating admission webhook mechanism [K8S-WEBHOOK] to inject the sidecar container into agent pods. The webhook intercepts pod CREATE events and applies JSON Patch [RFC6902] operations to the pod specification. The injection is automatic and transparent. Agent workloads do not need to be modified, recompiled, or even aware that the inference mesh exists. The webhook detects AI workloads using three mechanisms (Section 5.2) and injects the sidecar only into pods that match. The webhook MUST be configured as a MutatingWebhookConfiguration resource with failurePolicy set to "Fail" to ensure that pods cannot be created without sidecar injection if the webhook is unavailable. 3.3. Three Gates: LLM, Database, API The sidecar implements three enforcement gates, each specialized for a category of outbound call: LLM Gate (Section 6): Intercepts calls to language model endpoints. Detects model endpoints by URL pattern matching against a registry of known AI provider URLs (api.openai.com, api.anthropic.com, generativelanguage. googleapis.com, etc.) and by the presence of AI-specific headers (Authorization: Bearer with model-specific prefixes). Evaluates per-model trust requirements, model attestation (weights digest), and token/cost limits. Database Gate (Section 7): Intercepts calls to database endpoints. Parses the first keyword of SQL statements to classify the operation (SELECT = L0, INSERT = L1, UPDATE = L2, DELETE = L3, DROP/TRUNCATE/GRANT = L4). Detects PII columns by name pattern and applies elevated trust requirements. Enforces credential isolation: the agent never holds database credentials directly. API Gate (Section 8): Intercepts outbound HTTP calls to non-model API endpoints. Classifies requests by HTTP method (GET/HEAD = L0, POST = L1, PUT/PATCH = L2, DELETE = L3) and by route-specific policy overrides. Enforces OAuth scope requirements where applicable. All three gates share the same trust level model, the same evidence ledger, and the same revocation system. A single sidecar instance enforces all three gates. 3.4. Default Deny If no policy matches a given outbound call, the sidecar MUST refuse the call. This is the fundamental security posture of the inference mesh: nothing is permitted unless explicitly allowed. Default deny applies at every gate. If a model is not listed in the model_policies section of the trust policy, the default_level from the policy is used as the required trust level. If the agent's trust level is below the required level, the call is refused. 3.5. Evidence Ledger Every gate decision is recorded in the evidence ledger (Section 10). Records are JSON objects with mandatory fields including sequence number, decision kind, gate type, agent identity, target, trust levels, decision, reason, request digest, timestamp, and hash chain link. Each record is signed with ECDSA P-256 for non-repudiation. 3.6. Kill Switch Feed The sidecar subscribes to one or more kill switch feeds (Section 11.3) that publish signed revocation events. When a revocation event is received, the sidecar applies it immediately: the next gate evaluation for the revoked agent or model will be refused. 3.7. Credential Isolation Agent containers MUST NOT hold database credentials, API keys, or signing keys. The sidecar integrates with HashiCorp Vault or equivalent secret management systems to obtain credentials on behalf of the agent, use them for a single operation, and discard them. See Section 12. 3.8. Architecture Diagram The following diagram shows the inference mesh architecture for a single Kubernetes pod: +-------------------------------------------------------+ | Kubernetes Pod | | | | +-----------------+ +------------------------+ | | | | | AgentMesh Sidecar | | | | Agent | | | | | | Container |---->| +------------------+ | | | | | | | LLM Gate |--+---+--> LLM API | | (no creds, | | +------------------+ | | | | no direct | | | DB Gate |--+---+--> Database | | outbound) | | +------------------+ | | | | | | | API Gate |--+---+--> External API | +-----------------+ | +------------------+ | | | | | | | | +------------------+ | | | | | Evidence Ledger | | | | | | (hash-chained) | | | | | +------------------+ | | | | | | | | +------------------+ | | | | | Kill Switch Sub | | | | | +------------------+ | | | | | | | | +------------------+ | | | | | Vault Client | | | | | +------------------+ | | | +------------------------+ | | | | +------------------+ +--------------------+ | | | Policy ConfigMap | | Evidence emptyDir | | | | /etc/agentmesh/ | | /var/agentmesh/ | | | +------------------+ +--------------------+ | +-------------------------------------------------------+ | | v v +------------------+ +----------------------+ | Trust Authority | | Kill Switch Feed(s) | | (policy source) | | (revocation events) | +------------------+ +----------------------+ | v +------------------+ | HashiCorp Vault | | (credentials) | +------------------+ Figure 1: Inference Mesh Architecture for a Single Pod 4. Trust Levels The inference mesh defines five trust levels that classify the sensitivity of operations an agent may perform. Trust levels are ordinal: an agent at trust level N is permitted to perform all operations that require trust level N or lower. Trust levels are assigned to agents via policy (Section 4.7) or via X.509v3 certificate extensions (Section 4.8). Trust levels are assigned to operations via the gate that intercepts them: the LLM gate assigns trust levels to model calls, the Database gate assigns trust levels to SQL statements, and the API gate assigns trust levels to HTTP requests. The following sections define each trust level. The definitions are intentionally broad to permit domain-specific interpretation while maintaining a consistent ordinal relationship. 4.1. L0: Read-Only Trust Level 0 designates read-only, monitoring, and non- sensitive operations. An agent at L0 may observe but not modify. Operations classified at L0: o SQL: SELECT, SHOW, DESCRIBE, EXPLAIN o HTTP: GET, HEAD, OPTIONS o LLM: Models designated as L0 in policy (typically embedding models or small summarization models) An L0 agent MUST NOT be permitted to perform any write operation, invoke any function call, or delegate to another agent. L0 is the appropriate trust level for monitoring agents, log analysis agents, and read-only data retrieval agents. Mapping to IEC 62443: Security Level 1 (SL 1) -- protection against casual or coincidental violation. 4.2. L1: General Purpose Trust Level 1 designates general-purpose, standard operations. An agent at L1 may perform non-sensitive write operations and invoke standard LLM completions. Operations classified at L1: o SQL: INSERT (into non-sensitive tables) o HTTP: POST (to non-sensitive endpoints) o LLM: General-purpose models (GPT-4o, Claude Sonnet, etc.) without function calling An L1 agent MAY create new records but MUST NOT modify or delete existing records. L1 is the appropriate trust level for customer service agents, content generation agents, and general-purpose assistants. Mapping to IEC 62443: Security Level 1 (SL 1) -- protection against casual or coincidental violation, with basic logging. 4.3. L2: Specialist Trust Level 2 designates specialist operations that involve multi-step reasoning, delegation to other agents, or modification of existing data. Operations classified at L2: o SQL: UPDATE, CREATE TABLE, ALTER INDEX o HTTP: PUT, PATCH o LLM: Models with function calling enabled, models with access to external tools, models used for multi-step reasoning chains An L2 agent MAY modify existing records and MAY delegate tasks to other agents (subject to delegation trust requirements). L2 is the appropriate trust level for data processing agents, code generation agents, and research agents. Mapping to IEC 62443: Security Level 2 (SL 2) -- protection against intentional violation using simple means. 4.4. L3: Compliance-Logged Trust Level 3 designates operations in regulated domains: financial transactions, medical records, legal documents, and any operation that creates regulatory reporting obligations. Operations classified at L3: o SQL: DELETE (from any table), any operation on PII columns o HTTP: DELETE, any operation on financial/medical/legal API endpoints o LLM: Models used for financial analysis, medical diagnosis, legal research, or any inference whose output affects a regulated decision An L3 agent MUST have enhanced evidence logging: every operation MUST be recorded with the full request and response digests. L3 evidence records are subject to the retention requirements of the applicable regulation (minimum 5 years for financial, 7 years for medical, 10 years for nuclear). Mapping to IEC 62443: Security Level 3 (SL 3) -- protection against intentional violation using sophisticated means with moderate resources. 4.5. L4: Critical Trust Level 4 designates critical, destructive, or irreversible operations that require human approval before execution. Operations classified at L4: o SQL: DROP TABLE, DROP DATABASE, TRUNCATE, GRANT, REVOKE o HTTP: Any operation that causes irreversible state change (e.g., account deletion, production deployment) o LLM: Models used for safety-critical inference (autonomous vehicle control, medical device operation, power grid management) An L4 operation MUST NOT proceed without explicit human approval. The sidecar MUST refuse L4 operations automatically and record a "refuse" evidence record with reason "human_approval_required". The agent framework MUST implement a human-in-the-loop mechanism that obtains approval through an out-of-band channel (mobile authenticator, hardware token, or equivalent) before retrying the operation. Mapping to IEC 62443: Security Level 4 (SL 4) -- protection against intentional violation using sophisticated means with extended resources and state-specific skills. 4.6. Mapping to IEC 62443 Security Levels IEC 62443 [IEC62443] defines four Security Levels (SL 1-4) for industrial automation and control systems. The inference mesh trust levels map to IEC 62443 Security Levels as follows: Inference Mesh IEC 62443 Description Trust Level Security Level ------------------------------------------------------- L0 (Read-Only) SL 1 Casual/coincidental L1 (General) SL 1 Casual/coincidental L2 (Specialist) SL 2 Intentional, simple means L3 (Compliance) SL 3 Intentional, sophisticated L4 (Critical) SL 4 Intentional, state-level This mapping enables organizations operating under IEC 62443 to use inference mesh trust levels directly in their security level assessments. An agent operating at trust level L2 in an ICS environment satisfies the SL 2 requirements for access control, use control, and data integrity specified in IEC 62443-3-3. 4.7. Trust Level Assignment via Policy An agent's trust level is determined by the following resolution order. The first match wins: 1. Explicit trust level from certificate extension (OID 1.3.6.1.4.1.66339.1) -- highest priority. 2. Explicit trust level from pod annotation (agentmesh.io/trust-level) -- set by the deployer. 3. Agent binding in trust policy (agent_bindings map) -- exact match on agent ID. 4. Agent binding in trust policy with prefix match -- SPIFFE path matching with wildcard (spiffe://domain/ path/*). Longest prefix wins. 5. Namespace default in trust policy (namespace_defaults map) -- based on the agent's Kubernetes namespace. 6. Global default in trust policy (default_level) -- fallback. If no level is resolved through any of these mechanisms, the agent is assigned L1 (general purpose). The trust policy is a JSON document mounted as a Kubernetes ConfigMap at /etc/agentmesh/policy.json. The complete schema is defined in Appendix A. 4.8. Trust Level in X.509v3 Certificate Extensions Trust levels MAY be encoded in X.509v3 certificate extensions under the IANA PEN 66339 OID arc. When present, the trust level in the certificate takes precedence over policy-based assignment. See Section 9.1 for the full certificate profile. The trust level extension uses OID 1.3.6.1.4.1.66339.1 and encodes the trust level as a UTF8String containing the decimal representation of the trust level (e.g., "2" for L2). 5. Sidecar Injection 5.1. Mutating Admission Webhook Specification The AgentMesh mutating admission webhook MUST be deployed as a Kubernetes Deployment in the agentmesh-system namespace with the following configuration: o The webhook server MUST listen on HTTPS (port 443 by default) with a TLS certificate that is trusted by the Kubernetes API server. o The MutatingWebhookConfiguration MUST specify: - rules: operations ["CREATE"], apiGroups [""], apiVersions ["v1"], resources ["pods"] - failurePolicy: "Fail" (pods cannot be created if the webhook is unavailable) - sideEffects: "None" - admissionReviewVersions: ["v1", "v1beta1"] - namespaceSelector: matchExpressions that exclude kube-system, kube-public, and agentmesh-system namespaces o The webhook MUST respond to admission review requests within 10 seconds. If the response is not received within this timeout, the API server applies the failurePolicy. o The webhook MUST be idempotent: applying the webhook to the same pod specification multiple times MUST produce the same result. The webhook generates a self-signed ECDSA P-256 TLS certificate at startup. The CA bundle is output to stdout and MUST be configured in the MutatingWebhookConfiguration's caBundle field, either manually or via a cert-manager Certificate resource. 5.2. Detection Criteria The webhook uses three mechanisms to detect AI agent workloads that require sidecar injection: Namespace Label: If the pod's namespace has the label agentmesh.io/inject=enabled, all pods in that namespace receive the sidecar. This is the recommended mechanism for namespaces dedicated to AI workloads. Pod Annotation: If the pod has the annotation agentmesh.io/inject=true, the pod receives the sidecar. This mechanism is used for individual pods in mixed namespaces. Environment Variable Detection: If any container in the pod defines an environment variable that is a known AI provider marker, the pod receives the sidecar. The following environment variable names are detected: OPENAI_API_KEY ANTHROPIC_API_KEY OPENAI_API_BASE ANTHROPIC_API_URL OPENAI_BASE_URL OLLAMA_HOST HUGGINGFACE_API_KEY HF_TOKEN AZURE_OPENAI_ENDPOINT AZURE_OPENAI_API_KEY GOOGLE_AI_API_KEY GEMINI_API_KEY COHERE_API_KEY MISTRAL_API_KEY TOGETHER_API_KEY GROQ_API_KEY REPLICATE_API_TOKEN DEEPSEEK_API_KEY AGENTPASS_AGENT_ID AGENTPASS_URL Additionally, envFrom references to ConfigMaps whose name contains "openai" or "anthropic" (case-insensitive) trigger injection. Detection mechanisms are evaluated in the order listed. If any mechanism matches, the sidecar is injected. If the pod already has a container named "agentmesh-sidecar", injection is skipped (idempotency). 5.3. Sidecar Container Specification The injected sidecar container MUST have the following properties: Name: agentmesh-sidecar Image: Configurable via the SIDECAR_IMAGE environment variable on the webhook deployment. Default: ghcr.io/cybersecai/agentmesh-sidecar:latest Ports: A single TCP port (default 15009, configurable via SIDECAR_PORT) named "agentmesh". Environment Variables: AGENTMESH_PORT: The port the sidecar listens on. AGENTMESH_BIND: "0.0.0.0" (listen on all interfaces within the pod network namespace). AGENTMESH_POLICY: "/etc/agentmesh/policy.json" AGENTPASS_TRUST_LEVEL: (optional) Override trust level from pod annotation agentmesh.io/trust-level. AGENTPASS_AGENT_ID: (optional) Override agent ID from pod annotation agentmesh.io/agent-id. Volume Mounts: /etc/agentmesh/ (read-only): Policy ConfigMap mount. /var/agentmesh/ (read-write): Evidence ledger journal. Resources: requests: cpu 10m, memory 32Mi limits: cpu 100m, memory 64Mi Security Context: See Section 5.6. Readiness Probe: HTTP GET /healthz on the sidecar port, initialDelaySeconds 2, periodSeconds 5. Liveness Probe: HTTP GET /healthz on the sidecar port, initialDelaySeconds 5, periodSeconds 10. The agent container MUST route outbound calls through the sidecar. This is achieved by setting the HTTP_PROXY and HTTPS_PROXY environment variables in the agent container to point to the sidecar's port, or by using iptables rules (injected via an init container) to redirect outbound traffic. 5.4. Volume Injection The webhook injects two volumes into the pod specification: Policy ConfigMap Volume: name: agentmesh-policy configMap: name: agentmesh-policy optional: true The ConfigMap is marked as optional so that pods can be created before the policy ConfigMap exists. In this case, the sidecar uses default policy settings (default trust level L1, no model-specific policies). Evidence emptyDir Volume: name: agentmesh-evidence emptyDir: sizeLimit: 100Mi The evidence volume uses an emptyDir with a 100Mi size limit. The sidecar writes the evidence journal (evidence.jsonl) to this volume. The size limit prevents a runaway evidence ledger from consuming all node disk space. If an existing persistent volume is required for evidence that must survive pod deletion (not just restart), the deployer SHOULD create a PersistentVolumeClaim and reference it via the pod annotation agentmesh.io/evidence-pvc. 5.5. Opt-Out Mechanism A pod MAY opt out of sidecar injection by setting the annotation agentmesh.io/inject=false. This annotation takes priority over all detection mechanisms. Opt-out SHOULD be used only for pods that are known not to be AI workloads but that happen to define AI provider environment variables for other purposes (e.g., a monitoring pod that scrapes AI provider metrics). Organizations SHOULD implement Kubernetes admission policies (e.g., OPA Gatekeeper or Kyverno) that prevent unauthorized use of the opt-out annotation in production namespaces. 5.6. Security Context The sidecar container MUST run with the following security context: runAsNonRoot: true runAsUser: 1001 readOnlyRootFilesystem: true allowPrivilegeEscalation: false capabilities: drop: ["ALL"] This security context ensures: o The sidecar runs as a non-root user (UID 1001), preventing privilege escalation within the container. o The root filesystem is read-only, preventing an attacker who compromises the sidecar from modifying its binary or configuration on disk. o Privilege escalation is disabled, preventing setuid/setgid exploits. o All Linux capabilities are dropped, including CAP_NET_RAW, CAP_SYS_ADMIN, and CAP_NET_ADMIN. The sidecar does not require any capabilities because it communicates only via TCP sockets (which do not require CAP_NET_RAW) and writes only to the mounted evidence volume. 6. LLM Gate The LLM gate intercepts outbound calls from the agent container to language model endpoints. It is the first line of defense against unauthorized or excessive model usage. 6.1. Model Trust Requirements Each language model is assigned a trust requirement in the trust policy. The trust requirement specifies the minimum trust level an agent must have to call that model. Example policy fragment: { "model_policies": { "text-embedding-3-small": 0, "gpt-4o-mini": 1, "gpt-4o": 1, "gpt-4o-with-tools": 2, "claude-sonnet-4-20250514": 1, "claude-opus-4-20250514": 2, "o3-pro": 3, "medical-diagnosis-v2": 3, "autonomous-trading-v1": 4 } } If a model is not listed in model_policies, the default_level from the policy is used as the required trust level. 6.2. Per-Model Policy Evaluation When the LLM gate intercepts an outbound call to a model endpoint, it performs the following evaluation: 1. Identify the model. Extract the model name from the request body (e.g., the "model" field in an OpenAI- compatible chat completion request). 2. Check model revocation. If the model is in the revocation set, refuse the call with reason "model_revoked". 3. Check agent revocation. If the agent is in the revocation set, refuse the call with reason "agent_revoked". 4. Resolve the agent's trust level using the resolution order defined in Section 4.7. 5. Resolve the model's required trust level from model_policies or default_level. 6. Compare. If the agent's trust level is less than the model's required trust level, refuse the call with reason "insufficient_trust_level". 7. If the agent's trust level equals or exceeds the model's required trust level, admit the call. 8. Record the decision in the evidence ledger with gate_type "llm". The entire evaluation MUST complete before the request is forwarded to the model endpoint. The evidence record MUST be written and fsynced before the response is returned to the agent. 6.3. Model Attestation For self-hosted models (Ollama, vLLM, TGI, or equivalent), the LLM gate MAY verify model attestation before permitting inference. Model attestation provides assurance that the model weights have not been tampered with since they were approved. Model attestation uses the following mechanism: 1. The model operator computes a SHA-256 digest of the model weights file(s) and publishes the digest in a signed attestation document. 2. The attestation document is referenced in the trust policy: { "model_attestations": { "llama-3.1-70b": { "digest": "sha256:a1b2c3d4...", "signer": "https://models.example.com/.well-known/jwks.json", "signature": "base64url-encoded-signature" } } } 3. The LLM gate verifies the attestation signature against the signer's public key before admitting the first request to the model. 4. The verification result is cached for the lifetime of the sidecar process. Model attestation is OPTIONAL. When configured, attestation failure results in a refuse decision with reason "model_attestation_failed". 6.4. Inference Signing For every admitted LLM request, the sidecar SHOULD compute a SHA-256 digest of the request body and include it in the evidence record as the request_digest field. For every response, the sidecar SHOULD compute a SHA-256 digest of the response body and record it as a separate evidence record with kind "response". Inference signing creates a cryptographic chain from the agent's request to the model's response, enabling post-hoc verification that a specific model produced a specific output in response to a specific input. The signing mechanism is: 1. Compute request_digest = SHA-256(canonical(request_body)) 2. Compute response_digest = SHA-256(canonical(response_body)) 3. Record both digests in the evidence ledger. 4. The evidence record's ECDSA P-256 signature covers both digests, creating a non-repudiable link between input and output. 6.5. Token and Cost Enforcement The LLM gate MAY enforce token and cost limits on a per- agent, per-model, or per-namespace basis. Token limits are specified in the trust policy: { "token_limits": { "gpt-4o": { "per_request": 4096, "per_hour": 100000, "per_day": 1000000 } } } Cost limits are specified in the trust policy: { "cost_limits": { "default": { "per_hour_usd": 10.00, "per_day_usd": 100.00 } } } When a token or cost limit is exceeded, the LLM gate refuses the call with reason "token_limit_exceeded" or "cost_limit_exceeded" respectively. Token counting is performed by the sidecar by parsing the response body for the "usage" field in the model's response. Actual token counts from the model response are used for accounting; pre-request estimates are used only for pre- flight checks. 7. Database Gate The Database gate intercepts outbound calls from the agent container to database endpoints. It parses SQL statements to classify operations by sensitivity and enforces trust level requirements. 7.1. SQL Statement Classification The Database gate classifies SQL statements by parsing the first keyword of the statement. The following classification MUST be used: SQL Keyword Required Trust Level Rationale ------------------------------------------------------------------ SELECT L0 Read-only, non-destructive SHOW L0 Metadata inspection DESCRIBE L0 Schema inspection EXPLAIN L0 Query plan analysis INSERT L1 Creates new records UPDATE L2 Modifies existing records CREATE L2 Schema modification ALTER L3 Schema modification (risky) DELETE L3 Removes records DROP L4 Destroys tables/databases TRUNCATE L4 Removes all records GRANT L4 Modifies access control REVOKE L4 Modifies access control Multi-statement queries (separated by semicolons) MUST be classified by the highest trust level of any constituent statement. For example, "SELECT * FROM users; DROP TABLE users;" requires L4 because DROP is present. Stored procedure calls (EXEC, CALL) MUST be classified at the trust level specified in the trust policy for the specific procedure, or at the default_level if no policy exists. 7.2. PII Column Detection The Database gate SHOULD detect columns that contain personally identifiable information (PII) by name pattern matching. The following column name patterns are considered PII indicators: o email, e_mail, email_address o phone, phone_number, mobile, telephone o ssn, social_security, national_id o first_name, last_name, full_name, surname o address, street, city, zip, postal_code o date_of_birth, dob, birthday o passport_number, drivers_license o credit_card, card_number, cvv o ip_address, user_agent When a query references a PII column, the required trust level is elevated to at least L3, regardless of the SQL operation. For example, "SELECT email FROM users" requires L3 even though SELECT normally requires L0. The PII column list is configurable via the trust policy. Organizations SHOULD extend it with domain-specific column names. 7.3. Per-Table and Per-Column Enforcement The trust policy MAY specify per-table and per-column trust requirements: { "database_policies": { "tables": { "audit_log": {"min_level": 3, "write_level": 4}, "user_credentials": {"min_level": 4}, "public_content": {"min_level": 0} }, "columns": { "users.ssn": {"min_level": 4}, "users.email": {"min_level": 3} } } } Per-table and per-column policies take precedence over the SQL keyword classification. The effective required trust level is the maximum of the SQL keyword level, the table level, and the column level. 7.4. Credential Isolation The Database gate enforces credential isolation as defined in Section 12. The agent container MUST NOT have database credentials in its environment variables, mounted secrets, or configuration files. When the Database gate admits a query, it obtains a short- lived database credential from the secret manager (e.g., HashiCorp Vault database secrets engine), executes the query on behalf of the agent using that credential, and discards the credential immediately after use. The credential MUST NOT be returned to the agent. The agent receives only the query result. This isolation ensures that even if an agent is compromised (e.g., via prompt injection), the attacker cannot obtain database credentials because the agent never had them. 8. API Gate The API gate intercepts outbound HTTP calls from the agent container to external APIs. It classifies requests by HTTP method and route, enforcing trust level requirements. 8.1. HTTP Method Classification The API gate classifies HTTP requests by method. The following classification MUST be used: HTTP Method Required Trust Level Rationale ------------------------------------------------------------------ GET L0 Read-only, safe, idempotent HEAD L0 Read-only, safe, idempotent OPTIONS L0 CORS preflight, safe POST L1 Creates resources PUT L2 Replaces resources PATCH L2 Modifies resources DELETE L3 Destroys resources Unknown or non-standard HTTP methods MUST be classified at the default_level from the trust policy. 8.2. Route-Based Policy The trust policy MAY specify per-route trust requirements that override the HTTP method classification: { "model_policies": { "api:/api/v1/transfers": 3, "api:/api/v1/users/*/delete": 4, "api:/api/v1/deployments": 3, "api:/api/v1/public/*": 0 } } Route patterns support wildcard matching with "*" matching a single path segment and "**" matching zero or more path segments. The effective required trust level is the maximum of the HTTP method level and the route-specific level. For example, a GET to /api/v1/transfers requires L3 (the route level) even though GET normally requires L0. 8.3. Scope Enforcement When the outbound API call uses OAuth 2.0 [RFC6749], the API gate MAY enforce scope requirements. The trust policy specifies which OAuth scopes require which trust levels: { "scope_policies": { "read:users": 0, "write:users": 2, "admin:org": 3, "delete:*": 3 } } The API gate inspects the access token (if present) to determine the granted scopes and verifies that the agent's trust level is sufficient for all scopes in the token. If any scope requires a trust level higher than the agent's level, the call is refused. Scope enforcement is OPTIONAL. When not configured, the API gate relies solely on HTTP method and route classification. 9. Certificate Profile 9.1. X.509v3 Extensions under IANA PEN 66339 The inference mesh extends X.509v3 certificates with agent- specific information using extensions under the IANA Private Enterprise Number (PEN) 66339, registered to CyberSecAI Ltd. The OID arc 1.3.6.1.4.1.66339 is the base for all agent certificate extensions. The following sub-arcs are defined: OID Name Description ------------------------------------------------------------------ 1.3.6.1.4.1.66339.1 Trust Level Agent trust level (0-4) 1.3.6.1.4.1.66339.2.1 Jurisdiction Geo-jurisdictional binding 1.3.6.1.4.1.66339.3 Capabilities Agent capability set 1.3.6.1.4.1.66339.4 Protocol Protocol binding type 1.3.6.1.4.1.66339.5 Agent ID Unique agent identifier Trust Level (OID 1.3.6.1.4.1.66339.1): Encodes the agent's trust level as a UTF8String containing the decimal representation of the trust level. Values are "0", "1", "2", "3", or "4". This extension MUST be marked non-critical to permit interoperability with certificate consumers that do not understand agent extensions. Jurisdiction (OID 1.3.6.1.4.1.66339.2.1): Encodes the jurisdictional scope of the agent's operations. Values are ISO 3166-1 alpha-2 country codes or region identifiers (e.g., "EU", "UK", "US", "BR", "AE", "SG"). Multiple jurisdictions are separated by commas. This extension binds the agent's certificate to a specific legal jurisdiction for compliance purposes. Capabilities (OID 1.3.6.1.4.1.66339.3): Encodes the set of operations the agent is permitted to perform. Values are comma-separated capability tokens (e.g., "llm:read,db:select,api:get"). This extension provides fine-grained access control beyond trust levels. Protocol Binding (OID 1.3.6.1.4.1.66339.4): Indicates which protocol(s) the certificate is valid for. Values: "mcps" (MCP Secure), "attp" (Agent Trust Transport Protocol), "rest" (ATTP REST binding), "mesh" (inference mesh). Multiple values are comma-separated. Agent Identifier (OID 1.3.6.1.4.1.66339.5): A globally unique identifier for the agent instance. Format: URN or URI (e.g., "urn:agentpass:agent:a1b2c3d4" or "spiffe://example.com/agent/trading-bot-1"). 9.2. SPIFFE URI SAN Compatibility Certificates issued for inference mesh agents SHOULD include a SPIFFE ID as a URI-type Subject Alternative Name (SAN) in addition to the agent-specific extensions. This ensures compatibility with existing SPIFFE-aware infrastructure. The SPIFFE ID format for inference mesh agents is: spiffe:///agentmesh// Example: spiffe://example.com/agentmesh/production/trading-bot-1 When a certificate contains both a SPIFFE URI SAN and an Agent Identifier extension (OID 1.3.6.1.4.1.66339.5), the SPIFFE URI SAN takes precedence for identity resolution in SPIFFE-aware systems, and the Agent Identifier extension takes precedence in AgentMesh-aware systems. 9.3. Certificate Lifecycle Agent certificates are managed through the following lifecycle: Issuance: The sidecar requests a certificate from the inference mesh CA (or from an external CA such as cert-manager or SPIRE) at startup. The certificate request includes the agent's identity, trust level, jurisdiction, and capabilities as extension requests. Validity Period: Agent certificates SHOULD have a short validity period (1-24 hours) to limit the window of exposure if a certificate is compromised. Short-lived certificates reduce the need for explicit revocation. Rotation: The sidecar MUST rotate the agent's certificate before it expires. Rotation is performed by requesting a new certificate with the same identity and extensions. The old certificate is not revoked unless it has been compromised. Revocation: Agent certificates are revoked via the bilateral revocation mechanism (Section 11). Revocation is immediate: the sidecar refuses all operations for a revoked agent regardless of whether the certificate has expired. The CA SHOULD be hosted in a Hardware Security Module (HSM) or cloud KMS (e.g., AWS CloudHSM, GCP Cloud KMS, Azure Key Vault) to protect the CA signing key. The CA private key MUST NOT be exportable. 9.4. ASN.1 Encoding All agent-specific X.509v3 extensions use the following ASN.1 encoding: AgentTrustLevel ::= UTF8String (SIZE (1..1)) -- "0", "1", "2", "3", or "4" AgentJurisdiction ::= UTF8String (SIZE (2..128)) -- ISO 3166-1 alpha-2, comma-separated AgentCapabilities ::= UTF8String (SIZE (1..1024)) -- Comma-separated capability tokens AgentProtocolBinding ::= UTF8String (SIZE (1..128)) -- Comma-separated protocol identifiers AgentIdentifier ::= UTF8String (SIZE (1..512)) -- URN or URI All extensions MUST be marked non-critical. This ensures that certificate consumers that do not understand agent extensions can still validate the certificate for TLS purposes. The agent-specific extensions are informational to standard TLS libraries and normative only to inference mesh components. 10. Evidence Ledger The evidence ledger is the core compliance mechanism of the inference mesh. Every gate decision -- admit or refuse -- is recorded as a JSON object, hash-chained to the previous record, and signed with ECDSA P-256. 10.1. Record Format Each evidence record is a JSON object with the following mandatory fields: n (integer): Sequence number, starting at 0 for the first record. Monotonically increasing. kind (string): The type of event. Values: "admit", "refuse", "revoke", "startup", "shutdown". gate_type (string): The gate that produced this record. Values: "llm", "db", "api", "system". signer_id (string): The key identifier of the sidecar's signing key. This identifies which sidecar instance produced the record. agent_id (string): The identity of the agent whose operation was evaluated. This is the resolved agent identity from Section 4.7. target (string): The destination of the outbound call. For LLM calls: the model name. For database calls: the database endpoint and statement prefix. For API calls: the HTTP method and URL. trust_level (integer): The agent's current trust level (0-4). required_level (integer): The trust level required for this operation, as determined by the gate. decision (string): "admit" or "refuse". reason (string): Human-readable reason for the decision. For admits: "trust_level_sufficient". For refuses: "insufficient_trust_level", "agent_revoked", "model_revoked", "token_limit_exceeded", "cost_limit_exceeded", "model_attestation_failed", "pii_column_detected", "human_approval_required", "no_policy_match" (default deny). request_digest (string): SHA-256 hex digest of the canonical JSON serialization of the request body, or of the SQL statement for database calls. timestamp (string): ISO 8601 timestamp with timezone (e.g., "2026-08-25T14:30:00.000Z"). prev (string): SHA-256 hex digest of the previous record. For the first record (n=0), this is the genesis value: 64 zero characters ("0000...0000"). h (string): SHA-256 hex digest of this record, computed over the canonical JSON serialization of all fields listed above (n through prev, inclusive). signature (string): Base64url-encoded ECDSA P-256 signature over the bytes of the h field (interpreted as a hex string converted to bytes). 10.2. Hash Chaining Records are linked via SHA-256 hash chaining. The hash of each record is computed over the canonical JSON serialization [RFC8785] of the following fields, in this order: n, kind, gate_type, signer_id, agent_id, target, trust_level, required_level, decision, reason, request_digest, timestamp, prev The canonical JSON serialization uses RFC 8785 (JSON Canonicalization Scheme): keys are sorted lexicographically, no whitespace is used between tokens, and Unicode is serialized without escaping (except for characters that JSON requires to be escaped). The hash is computed as: h = SHA-256(JCS({n, kind, gate_type, signer_id, agent_id, target, trust_level, required_level, decision, reason, request_digest, timestamp, prev})) Where JCS() is the JSON Canonicalization Scheme function per RFC 8785. The first record in the chain uses prev = "0" * 64 (64 zero characters), which is the genesis value. This establishes the chain root. 10.3. ECDSA P-256 Signing Each record is signed with ECDSA P-256 (NIST FIPS 186-5). The signing process is: 1. Compute h = SHA-256(JCS(record_fields)) as defined in Section 10.2. 2. Convert h from hex string to bytes (32 bytes). 3. Sign the 32-byte hash with the sidecar's ECDSA P-256 private key using SHA-256 as the hash algorithm (effectively double-hashing, but the outer hash is internal to the ECDSA algorithm). 4. Encode the signature using base64url without padding. The sidecar generates an ECDSA P-256 key pair at startup. The public key is available via the /healthz endpoint for verification. In production deployments, the sidecar SHOULD use a key pair provisioned via KMS or Vault rather than a self-generated key pair. 10.4. Journal Persistence The evidence ledger is persisted as a JSONL (JSON Lines) file at /var/agentmesh/evidence.jsonl. Each line is a complete JSON object representing one evidence record. Write Durability: After appending each record, the sidecar MUST call flush() and fsync() on the file descriptor to ensure the record is persisted to the underlying storage. This prevents evidence loss due to container crash or node failure. Append-Only: The journal file MUST be opened in append- only mode. The sidecar MUST NOT seek, truncate, or overwrite any portion of the journal. Size Management: When the journal exceeds the configured size limit (default 100Mi, matching the emptyDir size limit), the sidecar SHOULD: 1. Compute a summary record containing the hash of the last record, the total number of records, and the time range covered. 2. Export the full journal to an external sink (e.g., S3, GCS, or a centralized evidence store). 3. Begin a new journal with a genesis record whose prev field references the summary hash from step 1. 10.5. Chain Verification Algorithm The evidence chain is verified by the following algorithm: Input: records[] -- ordered array of evidence records Output: verification_results[] -- per-record result prev = "0" * 64 // genesis value for each record r in records: issues = [] // 1. verify chain link if r.prev != prev: issues.append("chain link broken at record " + r.n) // 2. recompute hash expected_h = SHA-256(JCS({r.n, r.kind, r.gate_type, r.signer_id, r.agent_id, r.target, r.trust_level, r.required_level, r.decision, r.reason, r.request_digest, r.timestamp, r.prev})) if r.h != expected_h: issues.append("content altered") // 3. verify signature if not ECDSA_Verify(public_key, bytes.fromhex(r.h), base64url_decode(r.signature)): issues.append("signature does not verify") verification_results.append({ n: r.n, ok: len(issues) == 0, issues: issues }) prev = expected_h // use recomputed hash, not stored If any record fails verification, the entire chain from that point forward is considered untrustworthy. Auditors MUST NOT rely on records after a chain break without independent corroboration. 10.6. Restore on Restart When the sidecar starts, it MUST attempt to restore the evidence chain from the journal file. The restore process: 1. Open the journal file at /var/agentmesh/evidence.jsonl. 2. Read each line as a JSON object. 3. Reconstruct the Record objects with all fields including h and signature. 4. Set the internal sequence counter to the number of restored records. 5. Set the internal prev hash to the h field of the last restored record. 6. Log the number of restored records to stdout. If the journal file does not exist or is empty, the sidecar starts with an empty chain (sequence 0, prev = genesis). If the journal file is corrupted (e.g., truncated mid- record), the sidecar MUST restore all valid records up to the point of corruption and log a warning. The sidecar MUST NOT refuse to start due to a corrupted journal; it MUST resume from the last valid record. 10.7. Regulatory Mapping The evidence ledger satisfies the following regulatory requirements: EU AI Act Article 12: Article 12 requires that high-risk AI systems "shall technically allow for the automatic recording of events ('logs') over the lifetime of the system." The evidence ledger automatically records every gate decision without requiring agent cooperation. The hash chain and ECDSA signatures provide tamper evidence. The mandatory fields (agent_id, trust_level, decision, timestamp) directly address the Article 12(2) requirement for "the period of each use" and "the reference database against which input data has been checked." FDA 21 CFR Part 11: 21 CFR Part 11 requires electronic records to include audit trails that record the date, time, operator, and action for every record creation, modification, or deletion. The evidence ledger provides all of these fields. The ECDSA signature serves as the "electronic signature" required by 11.50. The hash chain provides the "secure, computer-generated, time-stamped audit trail" required by 11.10(e). IEC 62443-3-3: IEC 62443-3-3 SR 2.8 requires "Auditable events" that record "the type of event, the date and time of the event, the component that is the source of the event, the outcome (success or failure) of the event, and the identity of any user/subject associated with the event." Every evidence record contains these fields. NERC CIP-007-7: NERC CIP-007-7 R4 requires "security event monitoring" with "alerts for security events." The evidence ledger's "refuse" records serve as security event alerts. The hash chain provides the "log retention" required by CIP-007-7 R4.2. 11. Bilateral Revocation The inference mesh implements bilateral revocation: both agents and models can be revoked independently, and revocation propagates to every gate in every cluster. 11.1. Agent Revocation When an agent is revoked, every gate in every cluster MUST refuse all requests from that agent, regardless of the agent's trust level or the operation being attempted. Agent revocation is appropriate when: o The agent exhibits adversarial or anomalous behavior (e.g., repeated attempts to access resources above its trust level). o The agent's credentials have been compromised. o The agent's certificate has been revoked by the CA. o A human operator issues an emergency stop. When an agent is revoked, the sidecar: 1. Adds the agent ID to the local revocation set. 2. Refuses all subsequent requests from the agent with reason "agent_revoked". 3. Records a "revoke" event in the evidence ledger. Revocation is immediate and irreversible within a sidecar instance. To un-revoke an agent, a new trust policy must be deployed and the sidecar must be restarted. 11.2. Model Revocation When a model is revoked, every gate in every cluster MUST refuse all requests to that model, regardless of which agent is making the request. Model revocation is appropriate when: o The model has been found to produce unsafe, biased, or otherwise harmful outputs. o The model's weights have been tampered with (attestation failure). o The model provider has disclosed a security vulnerability. o A regulatory authority has ordered the model's withdrawal. When a model is revoked, the sidecar: 1. Adds the model identifier to the local revocation set. 2. Refuses all subsequent requests to the model with reason "model_revoked". 3. Records a "revoke" event in the evidence ledger. 11.3. Signed Revocation Feed Revocation events are distributed via signed feeds published by a trust authority. Each sidecar subscribes to one or more feed URLs configured in the trust policy (killswitch_urls). The feed endpoint returns a JSON document: { "head": 42, "entries": [ { "seq": 41, "revocation": { "subject": "agent", "id": "production/trading-bot-1", "reason": "adversarial_behavior", "timestamp": "2026-08-25T14:30:00Z" }, "feed_signature": "base64url-ECDSA-signature" }, { "seq": 42, "revocation": { "subject": "model", "id": "gpt-4o-compromised", "reason": "weights_tampered", "timestamp": "2026-08-25T14:31:00Z" }, "feed_signature": "base64url-ECDSA-signature" } ] } The sidecar polls the feed at a configurable interval (default 30 seconds). Each poll includes a "since" parameter indicating the last sequence number the sidecar has processed. Each feed entry is signed by the trust authority's ECDSA P-256 key. The signature covers the canonical JSON serialization of {"seq": N, "revocation": {...}}. The sidecar MUST verify the signature before applying the revocation. 11.4. Monotonic Sequence Numbers Feed sequence numbers MUST be monotonically increasing. If the sidecar receives a feed response where the head value is less than the last-seen sequence number, the sidecar MUST reject the entire feed response and log a warning. This prevents feed rollback attacks where an attacker replays an older version of the feed to "un-revoke" an agent or model. Sequence numbers MUST be integers. The sidecar MUST NOT process entries with non-integer sequence numbers. Entries within a feed response MUST be processed in sequence number order, regardless of the order in which they appear in the entries array. 11.5. Cross-Cluster Propagation In multi-cluster deployments, revocation feeds are the mechanism for cross-cluster propagation. All sidecars in all clusters subscribe to the same feed URL(s). When a revocation event is published, all sidecars receive it within one poll interval (default 30 seconds). For faster propagation, deployments MAY use: o WebSocket-based feeds that push revocation events immediately. o Kubernetes Custom Resource watches that propagate revocation events via the Kubernetes API. o Message queue subscriptions (e.g., NATS, Kafka) that deliver revocation events with sub-second latency. Regardless of the propagation mechanism, the sidecar MUST verify the signature on every revocation event before applying it. 11.6. Fail-Closed on Unreachable Feed If the sidecar cannot reach any configured kill switch feed for longer than a configurable timeout (default 5 minutes), the sidecar MUST enter a degraded mode where: o All L3 and L4 operations are refused with reason "killswitch_feed_unreachable". o L0, L1, and L2 operations continue to be evaluated normally. This fail-closed behavior ensures that an attacker who blocks the revocation feed cannot prevent revocation from taking effect for high-sensitivity operations. The timeout and degraded mode behavior are configurable via the trust policy. Organizations with strict security requirements MAY configure the sidecar to refuse ALL operations when the feed is unreachable. 12. Credential Isolation 12.1. Why Agents Must Not Hold Credentials In traditional microservice architectures, services hold their own credentials: database passwords in environment variables, API keys in mounted secrets, signing keys on the filesystem. This model is fundamentally unsafe for AI agents because: 1. Prompt injection can read environment variables. An adversarial prompt can instruct an agent to read its own environment variables and include them in its response. If the environment contains database passwords, those passwords are exfiltrated. 2. Tool calls can access the filesystem. If an agent has file system tools, an adversarial prompt can instruct it to read mounted secret files and return their contents. 3. Agent behavior is non-deterministic. Even without adversarial prompts, a sufficiently capable agent may autonomously decide to read its credentials as part of a debugging or troubleshooting chain of thought. 4. Credential scope is too broad. A database password grants full access to every table and every operation. There is no way to limit an environment-variable credential to SELECT-only access. The inference mesh eliminates this attack surface by ensuring that agent containers never hold credentials. The sidecar obtains credentials from a secret manager, uses them for a single operation, and discards them. 12.2. Vault Integration Pattern The inference mesh integrates with HashiCorp Vault [VAULT] using the following pattern: 1. The sidecar authenticates to Vault using the Kubernetes auth method (Section 12.3). 2. When a gate admits an operation that requires credentials (e.g., a database query), the sidecar requests a credential from Vault's appropriate secrets engine (e.g., the database secrets engine for database credentials, the KV secrets engine for API keys). 3. Vault returns a short-lived credential with a lease. 4. The sidecar uses the credential to execute the operation. 5. The sidecar discards the credential (zeroes the memory, does not cache). 6. If the lease is still active and the sidecar needs to perform another operation within the lease window, it MAY reuse the credential. Otherwise, it requests a new credential. The sidecar MUST NOT store credentials on the filesystem, in environment variables, or in any location accessible to the agent container. 12.3. Kubernetes Auth Method The sidecar authenticates to Vault using the Kubernetes auth method. This method uses the pod's service account token (available at /var/run/secrets/kubernetes.io/ serviceaccount/token) to authenticate. Authentication flow: 1. The sidecar reads the service account JWT from the mounted token file. 2. The sidecar sends a POST request to {vault_addr}/v1/auth/kubernetes/login with the JWT and the configured role name. 3. Vault validates the JWT against the Kubernetes API server, verifies the service account exists and is not deleted, and checks the role binding. 4. Vault returns a client token with a TTL matching the configured lease duration. 5. The sidecar caches the client token and renews it before expiry. The Vault role MUST be configured with a bounded service account list that includes only the service accounts used by agent pods. This prevents other pods from using the same role to obtain credentials. 12.4. Lease-Per-Statement Model For database operations, the inference mesh uses a lease- per-statement model: 1. Agent submits a SQL query to the sidecar. 2. The Database gate evaluates the query and decides "admit". 3. The sidecar requests a database credential from Vault's database secrets engine. The credential is a dynamically generated username/password pair with a short TTL (e.g., 60 seconds). 4. The sidecar opens a connection to the database using the dynamic credential. 5. The sidecar executes the agent's query. 6. The sidecar returns the query results to the agent. 7. The sidecar closes the database connection. 8. The sidecar revokes the Vault lease (or allows it to expire). This model ensures that: o Each query uses a unique credential. o Credentials are never exposed to the agent. o Even if the agent is compromised, there are no credentials to steal. o Database audit logs show distinct users for each query, enabling per-query attribution. 12.5. Credential Lifecycle The credential lifecycle for a single agent operation: Agent Sidecar Vault DB | | | | |-- query ---------> | | | | |-- evaluate gate ---> | | | | (admit) | | | |-- auth/k8s/login --> | | | |<-- client_token ---- | | | |-- db/creds/role ---> | | | |<-- username/pass --- | | | |-- SQL query -------> |-----------> | | |<-- result ---------- |<----------- | |<-- result -------- | | | | |-- revoke lease ----> | | | | (zero memory) | | Figure 2: Credential Lifecycle for a Database Operation 12.6. Attack Mitigation Credential isolation mitigates the following attack vectors: Prompt Injection -> Credential Theft: Attack: Adversarial prompt instructs agent to read environment variables or files containing credentials. Mitigation: No credentials exist in the agent's environment or filesystem. The agent cannot steal what it does not have. Container Escape -> Lateral Movement: Attack: Agent exploits container runtime vulnerability to escape the container and access host resources. Mitigation: Even on the host, there are no static credentials. Vault credentials are short-lived and may have already expired. The Vault token is bound to the sidecar's service account and cannot be used from a different context. Supply Chain -> Credential Exfiltration: Attack: Malicious dependency reads credentials from environment and sends them to an external server. Mitigation: No credentials exist in the environment. The malicious code has nothing to read. Memory Dump -> Credential Extraction: Attack: Attacker dumps the agent process memory to extract credentials. Mitigation: Credentials exist only in the sidecar process memory, for the duration of a single operation. The sidecar zeroes credential memory after use. 13. SPIFFE Interoperability 13.1. Accepting SPIRE-Issued SVIDs The inference mesh MUST accept SPIRE-issued X509-SVIDs as valid agent identity credentials. When a pod has a SPIRE agent running and issues SVIDs to workloads, the inference mesh sidecar uses the SVID's SPIFFE ID as the agent identity. The sidecar detects SPIRE integration by checking for the SPIFFE_ENDPOINT_SOCKET environment variable, which points to the Workload API Unix domain socket. If present, the sidecar: 1. Connects to the Workload API socket. 2. Calls FetchX509SVID to obtain the workload's SVID. 3. Extracts the SPIFFE ID from the URI SAN. 4. Uses the SPIFFE ID as the agent_id for trust level resolution and evidence recording. If the SVID contains agent-specific extensions under OID 1.3.6.1.4.1.66339, the sidecar extracts the trust level, capabilities, and other extensions from the certificate. 13.2. SPIFFE ID to Trust Level Mapping The trust policy maps SPIFFE IDs to trust levels via the agent_bindings configuration: { "agent_bindings": { "spiffe://example.com/agent/read-only-bot": 0, "spiffe://example.com/agent/general-assistant": 1, "spiffe://example.com/agent/data-processor": 2, "spiffe://example.com/agent/trading-bot": 3, "spiffe://example.com/agent/infrastructure-bot": 4 } } SPIFFE IDs are matched exactly. If no exact match is found, prefix matching is used (Section 13.3). 13.3. Longest Prefix Matching For SPIFFE IDs that do not have an exact match in agent_bindings, the sidecar uses longest prefix matching with wildcard entries: { "agent_bindings": { "spiffe://example.com/agent/trading/*": 3, "spiffe://example.com/agent/*": 1, "spiffe://example.com/*": 0 } } The wildcard "*" matches any suffix. When multiple wildcard entries match, the longest prefix wins. For example, the SPIFFE ID spiffe://example.com/agent/trading/bot-1 matches both spiffe://example.com/agent/trading/* (prefix length 42) and spiffe://example.com/agent/* (prefix length 33). The longest prefix wins, so the trust level is 3. Prefix matching uses the path portion of the SPIFFE ID only. The trust domain is always matched exactly. 13.4. Coexistence with Existing SPIRE Deployments The inference mesh is designed to coexist with existing SPIRE deployments without modification. The following principles govern coexistence: 1. No SPIRE configuration changes. The inference mesh does not require changes to SPIRE server configuration, SPIRE agent configuration, or registration entries. 2. No SVID modification. The inference mesh accepts SVIDs as-is. It does not require SPIRE to include agent- specific extensions in SVIDs (though it can use them if present). 3. Additive security. The inference mesh adds trust level enforcement, evidence generation, and bilateral revocation on top of SPIRE's identity layer. It does not replace or weaken any SPIRE security property. 4. Independent lifecycle. The inference mesh sidecar and the SPIRE agent have independent lifecycles. They can be upgraded, restarted, or removed independently. 5. Dual identity. When both SPIRE and AgentMesh are present, the agent has two identities: a SPIFFE ID (from SPIRE) and optionally an AgentPass identity. The sidecar resolves trust levels using both, with certificate-embedded trust levels taking precedence. 13.5. AgentMesh Certificates as Valid X509-SVIDs Certificates issued by the inference mesh CA MAY be structured as valid X509-SVIDs by including: 1. A URI-type SAN containing the SPIFFE ID. 2. The SPIFFE ID following the spiffe:// URI scheme. 3. A valid trust chain rooted in a trust bundle that is configured in the SPIRE trust domain. This enables AgentMesh-issued certificates to be consumed by SPIFFE-aware applications without modification. The agent-specific extensions (trust level, capabilities, etc.) are ignored by SPIFFE-unaware consumers because they are marked non-critical. 14. Deployment Models The inference mesh architecture supports multiple deployment models beyond Kubernetes. 14.1. Kubernetes: Sidecar via Admission Webhook The primary deployment model. The mutating admission webhook (Section 5) automatically injects the sidecar into agent pods. This is the only deployment model where injection is fully automatic. Prerequisites: o Kubernetes 1.24 or later (for stable admission webhook support) o The agentmesh-system namespace created o The webhook Deployment running with a valid TLS certificate o The MutatingWebhookConfiguration applied with the correct caBundle o Optionally: a trust policy ConfigMap deployed Deployment steps: 1. kubectl create namespace agentmesh-system 2. kubectl apply -f webhook-deployment.yaml 3. Wait for the webhook pod to start and print its CA bundle. 4. kubectl apply -f mutating-webhook-config.yaml (with caBundle populated) 5. kubectl apply -f policy-configmap.yaml (optional) 6. Label target namespaces: kubectl label namespace agentmesh.io/inject=enabled From this point, all new pods in labeled namespaces automatically receive the sidecar. 14.2. Docker Compose: Companion Container For Docker Compose deployments, the sidecar runs as a companion container in the same network namespace as the agent container. Example docker-compose.yml: services: agent: image: my-agent:latest environment: - HTTP_PROXY=http://agentmesh:15009 - HTTPS_PROXY=http://agentmesh:15009 depends_on: - agentmesh agentmesh: image: ghcr.io/cybersecai/agentmesh-sidecar:latest volumes: - ./policy.json:/etc/agentmesh/policy.json:ro - evidence:/var/agentmesh environment: - AGENTMESH_PORT=15009 - AGENTMESH_BIND=0.0.0.0 volumes: evidence: In Docker Compose deployments, the agent container MUST be configured to route traffic through the sidecar via HTTP_PROXY/HTTPS_PROXY environment variables. There is no automatic injection; the deployer is responsible for adding the sidecar to the Compose file. 14.3. Bare Metal: Reverse Proxy For bare metal deployments (agents running directly on a host without containerization), the sidecar runs as a reverse proxy process. The agent is configured to send all outbound requests through the proxy (via HTTP_PROXY/HTTPS_PROXY environment variables or application-level proxy configuration). The proxy intercepts requests, evaluates gates, records evidence, and forwards admitted requests to their destination. The sidecar binary is distributed as a standalone executable or installed via pip: pip install agentmesh-sidecar Configuration is via environment variables or a JSON configuration file at /etc/agentmesh/policy.json. 14.4. Serverless: Layer/Extension For serverless deployments (AWS Lambda, Google Cloud Functions, Azure Functions), the sidecar runs as a runtime layer or extension. AWS Lambda: The sidecar is packaged as a Lambda layer. The layer starts a local proxy on a designated port. The Lambda function code routes outbound requests through the proxy. Evidence is written to /tmp and exported to S3 at the end of each invocation. Google Cloud Functions: The sidecar runs as a background process started by the function's entrypoint script. Azure Functions: The sidecar runs as a custom handler extension. In all serverless models, the sidecar lifecycle matches the function invocation lifecycle. Evidence is exported to durable storage at the end of each invocation because the function's local filesystem is ephemeral. 14.5. Standalone: pip install For development and testing, the sidecar can be installed as a Python package: pip install agentmesh-sidecar agentmesh-sidecar --port 15009 --policy ./policy.json The standalone mode is suitable for: o Local development and testing o CI/CD pipeline testing o Single-agent deployments o Proof-of-concept demonstrations The standalone sidecar provides all gates, evidence ledger, and revocation features. It does not provide automatic injection (which requires a container orchestrator). 15. Security Considerations 15.1. Sidecar Compromise If the sidecar container is compromised, the attacker gains the ability to: o Admit all requests regardless of trust level. o Forge evidence records. o Access the sidecar's ECDSA signing key. o Access Vault tokens cached by the sidecar. Mitigations: o The sidecar runs with minimal privileges (Section 5.6): non-root, read-only filesystem, all capabilities dropped. o The sidecar image SHOULD be signed (e.g., with Cosign) and verified before deployment. The repository SHOULD include a cosign.pub file for verification. o The sidecar image SHOULD be built from a minimal base image (e.g., distroless or Alpine) to minimize the attack surface. o Network policies SHOULD restrict the sidecar's egress to only the destinations it needs: model endpoints, database endpoints, API endpoints, Vault, and kill switch feeds. o The sidecar's signing key SHOULD be provisioned from KMS or Vault rather than generated locally. This enables key rotation and audit of key usage. o Container runtime security tools (e.g., Falco, Tracee) SHOULD monitor the sidecar for anomalous behavior (unexpected network connections, process execution, or file access). 15.2. Policy ConfigMap Tampering The trust policy is stored in a Kubernetes ConfigMap. An attacker with write access to the ConfigMap can modify trust requirements to weaken enforcement (e.g., setting all required levels to L0). Mitigations: o Kubernetes RBAC MUST restrict ConfigMap write access to authorized principals only. The agent's service account MUST NOT have write access to the agentmesh-policy ConfigMap. o The policy ConfigMap SHOULD be managed by a GitOps tool (e.g., ArgoCD, Flux) that enforces review and approval for policy changes. o The sidecar SHOULD validate the policy against a schema and log warnings for policies that appear overly permissive (e.g., all levels set to 0). o Policy changes SHOULD be recorded in the evidence ledger as system events (kind "policy_change"). o Organizations SHOULD implement OPA Gatekeeper or Kyverno policies that validate the agentmesh-policy ConfigMap against organizational requirements (e.g., "production namespaces must not have default_level below 2"). 15.3. Evidence Ledger Integrity The evidence ledger is protected by hash chaining and ECDSA signatures. An attacker who gains write access to the evidence journal file can: o Append forged records (detected by signature verification if the attacker does not have the signing key). o Truncate the journal (detected by comparing the expected chain length against the actual length). o Modify existing records (detected by hash chain verification). The attacker cannot: o Modify a record without breaking the hash chain. o Forge a signature without the sidecar's private key. o Insert a record into the middle of the chain without breaking all subsequent hash links. For additional integrity, organizations SHOULD: o Export evidence to an immutable external store (e.g., S3 with Object Lock, GCS with retention policies, or a write-once-read-many storage system). o Periodically anchor the chain head hash to a trusted timestamping service (e.g., RFC 3161 TSA or OpenTimestamps) to prove the chain existed at a specific time. o Run independent verification of the evidence chain using the algorithm in Section 10.5. 15.4. CA Key Protection The inference mesh CA signing key is used to issue agent certificates. Compromise of the CA key allows an attacker to issue certificates with arbitrary trust levels and capabilities. The CA key MUST be stored in a Hardware Security Module (HSM) or cloud Key Management Service (KMS): o AWS CloudHSM or AWS KMS with HSM-backed keys o GCP Cloud KMS with HSM protection level o Azure Key Vault with HSM-backed keys o On-premises HSM (e.g., Thales Luna, Entrust nShield) The CA key MUST NOT be exportable. All signing operations MUST be performed within the HSM/KMS boundary. The CA SHOULD implement a two-tier hierarchy: o Offline root CA (air-gapped, used only to sign intermediate CA certificates). o Online intermediate CA (HSM-backed, used for day-to-day agent certificate issuance). This hierarchy limits the impact of a compromised intermediate CA: the root CA can revoke the intermediate and issue a new one without replacing all agent certificates. 15.5. Kill Switch Feed Authentication The kill switch feed is authenticated using ECDSA P-256 signatures. Every feed entry is signed by the trust authority's key. The sidecar MUST verify the signature before applying any revocation. An attacker who compromises the feed endpoint but not the signing key cannot inject fake revocations (because they cannot produce valid signatures). An attacker who blocks the feed triggers the fail-closed behavior (Section 11.6). The trust authority's public key MUST be configured in the sidecar via a trusted channel (e.g., a Kubernetes Secret or a certificate mounted from a ConfigMap). The public key MUST NOT be fetched from the same endpoint as the feed. For high-security deployments, the feed SHOULD use mutual TLS: the sidecar authenticates to the feed endpoint using its agent certificate, and the feed endpoint authenticates to the sidecar using the trust authority's certificate. 15.6. Network Policy Recommendations The following Kubernetes NetworkPolicy resources SHOULD be deployed alongside the inference mesh: 1. Deny all egress from agent containers except to the sidecar port: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: agent-egress-to-sidecar-only spec: podSelector: matchLabels: agentmesh.io/injected: "true" policyTypes: - Egress egress: - ports: - port: 15009 protocol: TCP 2. Allow sidecar egress to model endpoints, database endpoints, Vault, and kill switch feeds: (Specific network policy depends on the deployment's model endpoints and database endpoints.) 3. Deny all ingress to agent containers except from the sidecar (for response delivery). These network policies ensure that even if the sidecar is bypassed (e.g., via a container escape), the agent container cannot reach external resources directly. 16. IANA Considerations 16.1. PEN 66339 Reference This document references IANA Private Enterprise Number (PEN) 66339, which is registered to CyberSecAI Ltd. PEN 66339 was assigned by IANA on [date of assignment]. The PEN registration can be verified at: https://www.iana.org/assignments/enterprise-numbers/ 16.2. OID Arc Assignments The following OID arcs under 1.3.6.1.4.1.66339 are used by this document and are managed by CyberSecAI Ltd: OID Description ------------------------------------------------------------------ 1.3.6.1.4.1.66339.1 Agent Trust Level 1.3.6.1.4.1.66339.2 Jurisdictional scope (parent arc) 1.3.6.1.4.1.66339.2.1 Jurisdiction binding 1.3.6.1.4.1.66339.3 Agent Capabilities 1.3.6.1.4.1.66339.4 Protocol Binding 1.3.6.1.4.1.66339.5 Agent Identifier These OID assignments are made under the authority of PEN 66339 and do not require additional IANA registration. This document does not request any new IANA registrations. 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6902] Bryan, P., Ed., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . 17.2. Informative References [SPIFFE] SPIFFE Project, "Secure Production Identity Framework for Everyone (SPIFFE)", 2024, . [SPIRE] SPIFFE Project, "SPIRE: the SPIFFE Runtime Environment", 2024, . [K8S] The Kubernetes Authors, "Kubernetes Documentation", 2024, . [K8S-WEBHOOK] The Kubernetes Authors, "Dynamic Admission Control", 2024, . [ISTIO] Istio Authors, "Istio Service Mesh", 2024, . [LINKERD] Linkerd Authors, "Linkerd Service Mesh", 2024, . [VAULT] HashiCorp, "HashiCorp Vault", 2024, . [CERT-MANAGER] cert-manager Authors, "cert-manager: Cloud Native Certificate Management", 2024, . [IEC62443] International Electrotechnical Commission, "IEC 62443: Industrial Communication Networks -- Network and System Security", 2018. [EU-AI-ACT] European Parliament and Council, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", Official Journal of the European Union, August 2024. [FDA-21CFR11] U.S. Food and Drug Administration, "21 CFR Part 11: Electronic Records; Electronic Signatures", Code of Federal Regulations, Title 21. [NERC-CIP] North American Electric Reliability Corporation, "CIP Standards", 2024, . [MCPS] Sharif, R., "MCPS: Cryptographic Security Layer for the Model Context Protocol", draft-sharif-mcps-secure-mcp-03, March 2026. [AAT] Sharif, R., "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems", draft-sharif-agent-audit-trail-01, August 2026. [ATTP] Sharif, R., "ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server Communication", draft-sharif-attp-agent-trust-transport-00, March 2026. [X509-AGENT] Sharif, R., "X.509v3 Certificate Profile for Autonomous AI Agent Identity", draft-sharif-x509-agent-identity-profile-03, 2026. [COSIGN] Sigstore Project, "Cosign: Container Signing, Verification and Storage", 2024, . Appendix A. Complete Policy Schema The trust policy is a JSON document with the following schema. All fields are optional; the sidecar uses sensible defaults when fields are omitted. { "model_policies": { "": , ... }, "agent_bindings": { "": , ... }, "namespace_defaults": { "": , ... }, "default_level": 1, "killswitch_urls": [ "https://trust.example.com/feed" ], "vault_addr": "https://vault.example.com", "vault_role": "agentmesh-sidecar", "vault_secret_path": "database/creds/agent-role", "model_attestations": { "": { "digest": "sha256:", "signer": "", "signature": "" } }, "token_limits": { "": { "per_request": , "per_hour": , "per_day": } }, "cost_limits": { "default": { "per_hour_usd": , "per_day_usd": } }, "database_policies": { "tables": { "": { "min_level": , "write_level": } }, "columns": { "": { "min_level": } } }, "scope_policies": { "": }, "pii_columns": [ "", ... ], "killswitch_timeout_seconds": 300, "killswitch_degraded_max_level": 2 } Field Descriptions: model_policies: Maps model names to required trust levels. An agent's trust level must be >= the required level to call the model. Entries prefixed with "api:" are route- based API policies. agent_bindings: Maps agent identifiers (AgentPass IDs, SPIFFE IDs, or Kubernetes service accounts) to trust levels. Entries ending with "/*" are wildcard patterns. namespace_defaults: Maps Kubernetes namespace names to default trust levels. Used when no agent_binding matches. default_level: Global default trust level. Used when no other mechanism resolves a trust level. Default: 1. killswitch_urls: List of kill switch feed URLs. The sidecar polls these feeds for revocation events. vault_addr: HashiCorp Vault server address. If empty, credential isolation is not used. vault_role: Vault Kubernetes auth role name. vault_secret_path: Vault path for database credential generation. model_attestations: Maps model names to attestation data for self-hosted model verification. token_limits: Per-model token usage limits. cost_limits: Cost limits for model usage. database_policies: Per-table and per-column trust level requirements. scope_policies: OAuth scope to trust level mappings. pii_columns: Additional PII column name patterns beyond the built-in list. killswitch_timeout_seconds: Seconds before the sidecar enters degraded mode when feeds are unreachable. Default: 300. killswitch_degraded_max_level: Maximum trust level permitted during degraded mode. Default: 2. Appendix B. Kubernetes Manifest Examples The following manifests deploy the inference mesh in a Kubernetes cluster. B.1. Namespace apiVersion: v1 kind: Namespace metadata: name: agentmesh-system labels: agentmesh.io/inject: "false" B.2. Webhook Deployment apiVersion: apps/v1 kind: Deployment metadata: name: agentmesh-webhook namespace: agentmesh-system spec: replicas: 2 selector: matchLabels: app: agentmesh-webhook template: metadata: labels: app: agentmesh-webhook spec: containers: - name: webhook image: ghcr.io/cybersecai/agentmesh-webhook:latest ports: - containerPort: 8443 env: - name: SIDECAR_IMAGE value: ghcr.io/cybersecai/agentmesh-sidecar:latest - name: SIDECAR_PORT value: "15009" - name: SIDECAR_PULL_POLICY value: IfNotPresent - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP resources: requests: cpu: 50m memory: 64Mi limits: cpu: 200m memory: 128Mi securityContext: runAsNonRoot: true runAsUser: 1001 readOnlyRootFilesystem: true allowPrivilegeEscalation: false capabilities: drop: ["ALL"] B.3. MutatingWebhookConfiguration apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration metadata: name: agentmesh-inject webhooks: - name: inject.agentmesh.io admissionReviewVersions: ["v1", "v1beta1"] sideEffects: None failurePolicy: Fail clientConfig: service: name: agentmesh-webhook namespace: agentmesh-system path: /mutate port: 443 caBundle: rules: - operations: ["CREATE"] apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] namespaceSelector: matchExpressions: - key: agentmesh.io/inject operator: NotIn values: ["false"] - key: kubernetes.io/metadata.name operator: NotIn values: - kube-system - kube-public - agentmesh-system B.4. Trust Policy ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: agentmesh-policy namespace: default data: policy.json: | { "model_policies": { "text-embedding-3-small": 0, "gpt-4o-mini": 1, "gpt-4o": 1, "claude-sonnet-4-20250514": 1, "claude-opus-4-20250514": 2 }, "agent_bindings": { "spiffe://example.com/agent/*": 1 }, "namespace_defaults": { "production": 2, "staging": 1, "development": 0 }, "default_level": 1, "killswitch_urls": [ "https://trust.example.com/revocations" ] } Appendix C. Evidence Ledger Examples C.1. Startup Record { "n": 0, "kind": "startup", "gate_type": "system", "signer_id": "sidecar-abc123", "agent_id": "production/trading-bot-1", "target": "", "trust_level": 3, "required_level": 0, "decision": "admit", "reason": "sidecar_started", "request_digest": "", "timestamp": "2026-08-25T14:00:00.000Z", "prev": "000000000000000000000000000000000000000000000000000000000000000", "h": "a1b2c3d4e5f6...", "signature": "MEUCIQD..." } C.2. LLM Gate Admit { "n": 1, "kind": "admit", "gate_type": "llm", "signer_id": "sidecar-abc123", "agent_id": "production/trading-bot-1", "target": "gpt-4o", "trust_level": 3, "required_level": 1, "decision": "admit", "reason": "trust_level_sufficient", "request_digest": "e3b0c44298fc...", "timestamp": "2026-08-25T14:00:01.123Z", "prev": "a1b2c3d4e5f6...", "h": "f7e8d9c0b1a2...", "signature": "MEQCIAx..." } C.3. Database Gate Refuse { "n": 2, "kind": "refuse", "gate_type": "db", "signer_id": "sidecar-abc123", "agent_id": "production/trading-bot-1", "target": "postgres://db:5432 DROP TABLE users", "trust_level": 3, "required_level": 4, "decision": "refuse", "reason": "insufficient_trust_level", "request_digest": "d4e5f6a7b8c9...", "timestamp": "2026-08-25T14:00:02.456Z", "prev": "f7e8d9c0b1a2...", "h": "c3d4e5f6a7b8...", "signature": "MEYCIQC..." } C.4. Agent Revocation { "n": 3, "kind": "revoke", "gate_type": "system", "signer_id": "sidecar-abc123", "agent_id": "production/trading-bot-1", "target": "production/trading-bot-1", "trust_level": 3, "required_level": 0, "decision": "refuse", "reason": "agent_revoked", "request_digest": "", "timestamp": "2026-08-25T14:00:03.789Z", "prev": "c3d4e5f6a7b8...", "h": "b2c3d4e5f6a7...", "signature": "MEQCIBS..." } C.5. Chain Verification Output [ {"n": 0, "ok": true, "issues": []}, {"n": 1, "ok": true, "issues": []}, {"n": 2, "ok": true, "issues": []}, {"n": 3, "ok": true, "issues": []} ] Appendix D. IEC 62443 Compliance Matrix The following matrix maps IEC 62443-3-3 system requirements to inference mesh capabilities: IEC 62443-3-3 SR Description Inference Mesh ------------------------------------------------------------------ SR 1.1 Human user identification Agent identity via and authentication certificate or SPIFFE ID SR 1.2 Software process Agent certificate identification and with trust level authentication extension SR 1.7 Strength of password-based N/A: credential authentication isolation removes agent passwords SR 1.13 Access via untrusted Default deny + networks trust level gate SR 2.1 Authorization enforcement Trust level gate (L0-L4) SR 2.4 Mobile code LLM gate evaluates agent code/tool use SR 2.8 Auditable events Evidence ledger (hash-chained, signed) SR 2.9 Audit storage capacity Journal size mgmt with export SR 2.10 Response to audit Fail-closed on processing failures journal write failure SR 2.11 Timestamps ISO 8601 mandatory in evidence records SR 2.12 Non-repudiation ECDSA P-256 signatures on evidence records SR 3.4 Software and information Model attestation integrity (weights digest) SR 3.5 Input validation SQL statement parsing, PII detection SR 4.1 Information confidentiality Credential isolation via Vault SR 4.3 Use of cryptography ECDSA P-256, SHA-256, TLS 1.3 SR 7.6 Network and security Kill switch feed configuration settings for emergency response Appendix E. NERC CIP Compliance Matrix The following matrix maps NERC CIP standards to inference mesh capabilities for deployments in the electric utility sector: NERC CIP Standard Requirement Inference Mesh ------------------------------------------------------------------ CIP-003-9 R2 Cyber security policies Trust policy ConfigMap (auditable, versioned) CIP-004-7 R4 Access management Trust levels restrict agent operations to authorized scope CIP-005-7 R1 Electronic Security Network policies + Perimeter sidecar-only egress CIP-007-7 R4 Security Event Evidence ledger Monitoring records all gate decisions CIP-007-7 R5 System Access Controls Credential isolation prevents agent credential misuse CIP-008-6 R1 Cyber Security Incident Kill switch feed Response Plan provides immediate revocation CIP-010-4 R1 Configuration Change Policy changes Management and recorded in evidence Vulnerability ledger Assessments CIP-011-3 R1 Information Protection PII column detection + elevated trust requirements Acknowledgments The author acknowledges the contributions of the open-source community to the container security ecosystem, including the SPIFFE/SPIRE project, cert-manager, and the Kubernetes project. Author's Address R. Sharif CyberSecAI Ltd Email: raza@cybersecai.co.uk