Security and Compliance

Security in ContextOS is a cross-plane contract, not a perimeter add-on. The Trust plane defines the deterministic decisions an implementation must make before any side effect can occur.

Definition

A coordinated set of deterministic policy enforcement; user and agent identity; native ActionRisk; v1 approval-mode compatibility; typed capability, evidence, and effect boundaries; trace correlation; and replayable records. Cryptographic provenance and attestation are optional deployment profiles. No authorization control depends on model self-policing.

Why it exists

Agents act on production systems. Prompts leak, tools misbehave, models drift, third parties go rogue. Security has to be enforced where actions actually happen — at the Tool Gateway, at the policy boundary, at the memory promotion gate, at the sandbox kernel — and recorded in a way that survives audit and incident response.

How it works

1. Compile-time controls — the Context Pack Compiler emits runtime_controls (must_refuse, must_escalate, approval_gates_active, redaction_rules_active) baked into the prompt manifests.
2. Plan-time controls — the Critic verifies plans against tool allow-lists, evidence requirements, capability bindings, and the v1 compatibility ceiling.
3. Execute-time controls — the Tool Gateway re-evaluates identity, schemas, arguments, ActionRisk, approval state, destination, data scope, budget, and idempotency.
4. Memory-write controls — the memory promotion pipeline gates writes by class, contradiction check, and consent.
5. Audit — policy decisions, gate verdicts, tool exchanges, and memory promotions are correlated to the trace_id. Deployments that claim tamper evidence add a declared signing/hash-chain profile and verify it during replay.

Before work, derive actual features and negotiate exact required profiles/controls without demotion. At dispatch and every proactive wake/resume, check current trusted authority/revocation, complete stored action approval where required, observed boundary/data routes and original aggregate budget. The Execution Contract supplies deterministic validators and attachment schemas; production brokers, stores, sandboxes and provider adapters supply actual enforcement. Applicable policy-expression errors stop compilation with safe structured ContextCompileError, never a silently false predicate or successful partial context.

Threat model

ContextOS treats the agent system as multi-principal under partial trust, following the framing in Trusted AI Agents in the Cloud:

• The agent provider ships agent code and policies.
• The model provider ships base and tuned models.
• The tool ecosystem (MCP servers, OpenAPI services, A2A peers) defines capabilities.
• The cloud / runtime hosts execution.
• The enterprise / user delegates authority and demands proof.

The deployment must state its trusted computing base, threat/failure assumptions, allowed effects and residual risks. ContextOS’s normalized reference observations assume trusted brokers/controllers and atomic protected stores; serialized claims cannot authenticate themselves. Containing a compromised model/tool/tenant is an enforcement objective to test, not a proven property of these schemas. Host, privileged enforcer, hardware, side-channel and availability threats need explicit additional analysis rather than being inferred covered by a backend name.

Attack classes the architecture defends against

OWASP Agentic Applications 2026 mapping

This mapping is informative; OWASP’s Agentic Applications 2026 publication remains authoritative.

The architecture also references MITRE ATLAS tactics for AI-system threat modeling; per-intent adversarial suites are tracked via the Attack Success Rate metric described in the trusted-cloud reference.

Defense in depth

Use independent enforcement points so failure of one check does not automatically grant authority elsewhere. Demonstrate that separation under the declared threat model; the reference alone does not prove resistance to compromise.

Boundary enforcement model

Every plane boundary is a deterministic check, not a model check:

• Context → Decision — CompiledContext only contains capabilities the Compiler resolved through Registry ∩ Permissions − Prohibitions, native-risk policy, and the v1 safety-mode ceiling.
• Decision -> Action — the Critic re-verifies the Plan; the Tool Gateway re-validates each ToolCallEnvelope at execution time.
• Action → External — current workload and applicable delegated-user authority are verified; a trusted broker supplies scoped credentials outside model-visible state, while actual destination/data checks remain independent.
• Memory write — authorized minimized capture and promotion preserve provenance, required consent, namespace/readers, classification and contradiction checks under explicit retention.
• External → Audit — every accepted, denied, partial, or ambiguous effect emits a typed correlated record. A deployment claiming tamper evidence must additionally verify its declared signature or chain profile.

Identity propagation

User and agent identities flow through every Run Context. Agent workload identity is required; registry URNs, delegated user authority, and short-lived signed claims are conditional surfaces:

• Delegated user identity — optional run_context.user.delegation carries an OAuth-style token reference, scopes, and subject claims. It is required when native authority is user_delegated or policy requires on-behalf-of authority.
• Agent registry identity — run_context.agent.agent_urn is a versioned subject such as agent:contextos/support-refund@1.2.0. Used for ownership, lifecycle, manifest-scoped permissions, and audit.
• Agent workload identity — run_context.agent.workload_identity is a SPIFFE-style URI (spiffe://contextos/agents/<role>). Used for service-to-service auth and for non-delegated calls.
• Agent identity claim profile — optional run_context.agent.identity_claim binds the registry subject, workload, tenant, run ID, principal chain, scopes, expiry, and key ID for this run or A2A hop.

In the canonical v1 ToolCallEnvelope, the actor path is represented by principal_chain and an opaque auth_ref; it does not embed the full AgentIdentity or mandate a signature. The full identity remains in the originating RunContext and implementation audit store. A signed IdentityClaim is available as a profile in the type surface when a deployment can mint and verify it.

Token chaining and minimum privilege

• Delegation tokens are exchanged at the Gateway for per-call scoped credentials (STS-style); long-lived bearer tokens never reach an adapter.
• Scopes on the exchanged credential are the intersection of every applicable source: delegated-user scopes, optional identity-claim scopes, permission scopes, and the capability’s declared scope set—never the union.
• A2A hops do not forward the inbound delegation token or blindly reuse the parent claim. The receiving agent re-attests its workload identity, receives a fresh narrower child claim, and re-evaluates its own policy bundle. See A2A trust boundary.

Workload identity rotation and revocation

• Agent workload identities rotate on a fixed cadence; rotation is a signed change recorded against the agent registration.
• A workload identity that fails attestation is denied at the Gateway before any policy is evaluated; this is logged as security_event:workload_identity_attestation_failed.
• Agent signing keys rotate under change control. Historical keys may remain trusted only for replay until a declared deprecation window expires.
• A revoked agent registration is removed from active discovery and denied at claim minting, A2A dispatch, and Tool Gateway execution.
• Claim hashes, key IDs, agent URNs, and principal-chain summaries are logged; raw bearer tokens and raw signing secrets are never logged.

Native risk and v1 compatibility

The five v1 modes (read_only / local_write / network / delegated / destructive) are defined in Governance. They are compatibility labels, not a complete security model. Native policy evaluates effect, authority, reversibility, interaction, data scope, and actual arguments independently.

• read_only — no mutation; reads still require current reader/service authority, brokered credentials where needed, data policy and any approval obligation selected for the actual context.
• local_write — idempotency required; tenant-scoped credentials; full audit.
• network — egress allow-list; per-(tenant, capability) rate budget.
• delegated — valid user delegation token required; scopes minimum-privilege; per-call evidence captured.
• destructive — conservative v1 signal for the highest-impact legacy class; native risk and policy determine whether a named approval gate, frozen evidence snapshot, or other obligation is required.

Policy may select a lower effective approval mode for a specific bounded request only when the native vector, actual arguments, and capability ceiling permit it. The projection must remain conservative.

Prompt injection defense

Prompts in ContextOS are treated as untrusted by default. The defense is structural, not heuristic:

• Compile-time isolation. The Context Pack Compiler emits typed buckets (policy / tool / evidence / memory / business / session). Untrusted strings (KG documents, tool outputs, memory recall) flow through evidence and memory buckets that the Critic understands as advisory, not authoritative.
• Tool surface narrowing. Surface only eligible tools, and reject unsurfaced capabilities at the actual gateway even if a model guesses their name. Discovery/prompt visibility alone cannot prevent bypass through unrestricted code, credentials or network access.
• Deterministic policy outside the model. Every ToolCallEnvelope re-evaluates policy at the Gateway. Even if the model is fully manipulated by an injected instruction, the call is denied unless deterministic policy permits it.
• Argument constraints, not just tool gates. arg_constraints (regex, enum, min/max, idempotency key required) bound the values the model can submit. An injection that says “send to attacker@…” against a capability with to_in: ["@…"] returns denied.
• Redaction enforcement. runtime_controls.redaction_rules_active names obligations; the pure compiler does not execute regex/classifier redaction. A separate enforcer minimizes payloads before model exposure and tool/result/telemetry use, with approved source/result/action/recipient transformation proof where the data policy requires it.
• Critic re-verify before execute — the plan’s tools, arg shapes, and intent class are re-checked deterministically.
• Default deny on every plane boundary. An unrecognized capability, scope, or destination denies; it does not fall through.

Include indirect injection from third-party content in authorized useful/denied evaluations. Control/data separation, current capabilities and actual data routes reduce authority-laundering paths; no rendering rule or model score establishes universal injection resistance.

Tenant isolation

• Every read in the Knowledge Graph and every recall in Memory is scoped by tenant_id at the storage layer, not by application code.
• The Tool Gateway rejects any ToolCallEnvelope whose argument-derived tenant scope does not match run_context.tenant_id.
• Cross-tenant traversal denials emit minimized security evidence with the capability and protected correlation refs. Do not copy forbidden tenant values into broadly visible logs. Alert by the workflow’s incident policy; a correctly denied attempt is distinct from successful unauthorized access.
• Adapter credentials are scoped per tenant; the Tool Gateway exchanges them per call rather than holding long-lived bearer tokens.
• Caches and read-only aliases use tenant/owner/namespace and complete relevant input/policy pins. Enforce actual reader checks and test isolation; a key convention cannot prove cross-tenant access impossible. Shared devices do not merge personal, household or employer trust domains.

Cryptographic deployment profile

The core contract carries provenance and optional audit fields. Implementations requiring cryptographically verifiable provenance may adopt this profile and its trust-root/key-compromise assumptions; signatures are not mandatory fields on every base schema and do not prove semantic correctness.

Optional hash-chained audit

A deployment may store Decision Records, tool transcripts, and policy decisions in an append-only, hash-chained log keyed by trace_id. If enabled, the chain algorithm, canonical serialization, signer, rotation rules, and gap semantics must be versioned and tested. The current DecisionRecord.audit fields can reference this evidence but do not themselves implement a ledger.

Key management

• Signing keys are stored in a KMS; the runtime never holds a raw private key.
• Rotation is a signed change recorded against the registry; verifiers accept any non-revoked key within the rotation window.
• Revoked keys remain queryable for replay of historical runs against the keys valid at that time.

Secrets and credential exchange

The trusted credential broker owns secret material; the Gateway and model-visible artifacts carry only permitted opaque references. Declare which trusted enforcer/provider endpoint can receive a scoped credential under the actual protocol.

• Scoped issuance. Verify tenant, principal/owner, purpose, capability/revision, resource/destination, lifetime and delegated ancestry/revocation. Broker credentials under the actual provider protocol; service work need not manufacture human delegation. UserClaims.user_id, delegation.subject and permission constraints retain their base shapes.
• Vault references, not model-visible values. Use declared identity token_ref and tool auth_ref fields or separately versioned broker metadata. Credential material stays with the trusted broker/enforcer and reaches only its authorized endpoint; do not invent required top-level auth.* token fields or claim every adapter protocol can avoid handling credentials identically.
• No secret transit through the model. Secrets that must reach a tool (e.g., per-tenant API keys) bypass the Compiler — they are resolved at the Gateway from the (tenant, capability) mapping.
• Permitted env vars (sandbox) are an explicit allow-list. The closed list is defined per profile and signed.
• Rotation. Rotation cadence per credential class is declared at the adapter; the registry refuses adapters without a declared rotation contract.

Egress controls

Any enabled outbound path, including a read, inference, telemetry, code worker or child agent, needs mediation. The Gateway/egress enforcer constrains the actual path. Names such as endpoint_in[] and pinned_sha256[] below belong to a declared deployment policy, not extra required base adapter fields:

• Destination policy. Restrict exact origins, ports and routes appropriate to the workload at the actual broker/network boundary; prevent direct bypass and disallowed private/metadata destinations.
• DNS and redirect mediation. Verify resolved addresses and every redirect against destination policy, including rebinding/CNAME changes; a permitted hostname or business allow alone is insufficient.
• TLS pinning (optional) per capability via pinned_sha256[] of acceptable certificate fingerprints; rotation is a signed registry change.
• Rate budget. Every (tenant, capability) declares a per-window rate; the Gateway returns denied with error_code: rate_exceeded rather than queueing.
• Egress audit. Every outbound request emits a span carrying trace_id, policy_decision_id, capability id, and destination — sufficient for traffic-side reconciliation against the Decision Record.

Data classification and redaction

Bind verified source classification to every applicable data flow, through declared metadata/attachments without inventing required fields on each base envelope. This table illustrates a strict deployment default; actual permitted processing, transformations, recipients and retention are explicit policy decisions:

Redaction rule names live in runtime_controls.redaction_rules_active; production enforcers apply them before exposure. The compiler emits obligations and accepts caller-supplied verification labels, so it cannot establish that masking or source authentication actually happened. A required transformation/enforcement failure blocks the prohibited route and release claim.

Check actual source labels, purpose, recipient/processor, residency and approved transformation evidence across collection, inference, tool input/output, telemetry, cache, memory, export and delegation. A declared region or retention band alone is insufficient. Refs/hashes can reveal sensitive relationships and need the same minimization and reader/retention discipline.

Memory-write controls

Memory is a primary security boundary because it is the channel by which untrusted content can persist into future runs.

• Capture is governed. Authorized minimized observations preserve provenance and correlation under explicit retention. Append-only audit does not permit indefinite retention of forbidden raw payloads.
• Promotion is explicit. Verify the applicable consent/purpose conditions, contradiction handling and classification/readers policy. This page’s strict illustrative default denies RESTRICTED promotion; actual permitted classes and transformations are pinned deployment policy, not inferred from confidence.
• Permission evidence. Retain the owner-reviewed purpose/permission basis and required consent evidence. A candidate’s consent_check: passed flag cannot authenticate that basis, and operator policy cannot override an applicable legal or protected data requirement.
• Tenant scoping. Memory recall scopes by tenant_id and subject claims; a cross-subject recall is a security_event:memory_cross_subject_denied.
• Correction and erasure. Track the complete scoped copy inventory across stores, indexes, caches and controlled exports. An allowed deletion may remain pending/failed; only verified current bound receipts for every required target establish scoped completion. Unknown external copies remain explicit. Retention exceptions, backups and provider-training effects require separately evidenced policy and escalation.

Sandbox controls

For tool capabilities that execute untrusted code (e.g., user-provided scripts in a research workflow), the runtime exposes a Sandbox layer as a first-class component, not as a tool feature flag.

Sandbox profiles

A sandbox configuration is a versioned deployment protocol, distinct from an exact standard control profile. The illustrative JSON below is not a new base exported sandbox type; its historical kernel label selects a backend rather than asserting Docker or a hosted service is an OS kernel. The canonical ExecutionBoundaryRequirement / ExecutionBoundaryObservation attachments compare required configuration with trusted current active observations. Deployments may additionally require supply-chain signatures.

{
  "sandbox_profile_id": "sbx_research_default",
  "version": "1.0.0",
  "kernel": "docker",
  "image_pin": "sha256:...",
  "filesystem": { "host_mount": [], "tmpfs_mb": 256 },
  "network": { "ingress": "deny", "egress": "deny", "allowlist": [] },
  "compute": { "cpu_cores": 1.0, "memory_mb": 512, "wall_clock_ms": 30000 },
  "stdio": { "stdin_max_bytes": 65536, "stdout_max_bytes": 1048576, "stderr_max_bytes": 1048576 },
  "secrets": { "permitted_env_vars": [] },
  "result_classification": "INTERNAL"
}

Sandbox kernels

Invariants

• Default deny everything. Capabilities that need code execution must reference a registered sandbox_profile_id; profiles cannot be inlined.
• No host filesystem by default. Any host_mount requires a separate operator approval recorded as a versioned change, with a signature when the supply-chain profile requires one.
• No inbound network. Egress only via explicit allowlist.
• Hard wall-clock and memory caps enforced by the kernel, not the adapter.
• Output is governed data. Bound stdout/stderr size and classification; validate permitted immediate model/tool use as data-only. Persistent memory additionally requires the promotion/lifecycle pipeline; a transient tool result need not become promoted memory.
• Image pinning is mandatory. Tag-based image references (latest, stable) are refused.
• Required active controls. Observe current configuration digest, enforcer identity, validity/age, filesystem/process/network/credential mediation and resource ceilings appropriate to enabled work. If policy additionally requires attestation, verify its trust root, measurement, nonce/freshness and binding. Missing required controls block without host or weaker-backend fallback.
• No secrets transit. permitted_env_vars is the closed allow-list; the sandbox never sees the broader credential store.

Lifecycle

• Profile authored under change control with required reviewer (security_lead).
• Promoted into the pack registry alongside Context Packs.
• Bound through the deployment’s admitted capability/boundary registry; sandbox_profile_id is a local extension, not a required base AdapterDefinition field.
• Retired profiles remain queryable for replay; cannot be re-promoted without a new version.

A2A 1.0 trust profile

A2A 1.0 supplies discovery, messages, artifacts, task lifecycle, and authentication metadata. ContextOS supplies the local authority decision around each hop:

• Agent Cards are discovery, not admission. Verify provenance and apply registry/policy review before making a peer reachable.

• No delegation forwarding. The receiving agent does not inherit the caller’s delegation token. It re-attests its own workload identity and re-evaluates its own policy bundle against the original run_context.user.

• Narrow child authority. A parent A2A call authorizes a child through the narrower AgentDelegationEnvelope; deployments using the identity-claim profile also mint a fresh signed claim whose scopes are a subset of the parent and receiver ceilings.

• Typed message envelopes with explicit correlation_id and parent_decision_id so the receiving Decision Record links to the parent for replay.

• Risk does not disappear at a hop. The receiving implementation recomputes native risk and authority; the parent v1 mode is lineage, not permission.

• Per-hop audit. Every A2A message emits correlated sender/receiver workload and principal-chain evidence; optional agent URNs, claim hashes, and signature verification are recorded when those profiles are active.

• Loop guard. A2A graph depth and cycle detection are enforced by the Orchestrator; cycles are rejected with error_code: a2a_cycle_detected.

Intersect verified grants and revocation across every ancestor and owner/root/child scope. Actual child recipients and output labels remain governed; a natural-language instruction cannot launder tool data into control. Reserve child capacity from the original aggregate budget/deadline, propagate cancellation and fence stale workers. Parent history, Agent Cards and serialized delegation do not authenticate a grant or authorize sharing another tenant’s data.

Supply chain

The runtime treats every artifact as supply-chain-relevant:

• Context Packs. Pack registry holds immutable pack_id@semver artifacts with content identity and a dependency tree; an adopted supply-chain profile adds signer and provenance evidence.
• Adapters. Each adapter declares image hash (for hosted), source repo + commit (for in-repo), and the auth contract. Tag-based references are refused.
• Models. Record the provider/model identifier and deployment revision or profile available from the provider. Do not claim a content hash for an opaque hosted model.
• Sandbox images pinned by content hash; tag references like latest / stable are rejected at profile validation.
• Build provenance profile. Deployments can produce packs and adapters through CI with Sigstore-compatible provenance; a registry claiming this profile refuses artifacts whose attestation does not verify.

Attestation

For deployments requiring cryptographic runtime provenance, the trusted-cloud research mapping discusses differential attestation under explicit hardware/TCB assumptions. Bind verified measurements, freshness/nonce, complete artifact/input/action/result digests and verifier trust policy in a separately versioned evidence artifact. A DecisionRecord.inputs_refs entry or declared linked evidence can reference it; attestation_ref is not a new required top-level v1 field. Attestation does not prove model correctness, business authority, downstream provider completion or freedom from excluded side-channel/availability threats.

This is optional infrastructure, not a baseline requirement. Deployments without attested execution still retain typed, correlated, replay-oriented evidence; hash chaining and signed Decision Records are separate optional profiles.

Boundary controls (this repo)

This repo is the public spec surface. Even there, controls are explicit:

• Centralized security headers in next.config.ts: Content-Security-Policy (default-src 'self', script-src includes 'wasm-unsafe-eval' for Pagefind WebAssembly search without enabling production 'unsafe-eval', frame-ancestors 'none', object-src 'none', upgrade-insecure-requests, block-all-mixed-content), Strict-Transport-Security (max-age=63072000; includeSubDomains; preload), X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy: camera=(), microphone=(), geolocation=(), X-Content-Type-Options: nosniff, Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Resource-Policy: same-origin for pages with cross-origin on static and generated social preview image routes, X-Permitted-Cross-Domain-Policies: none.
• Optional review-deployment Basic Auth via src/proxy.ts (gated by BASIC_AUTH_ENABLED, bypassed for development, loopback and canonical public hosts, with matcher exclusions). This convenience gate is not agent authorization or a general tenant-isolation service.
• CI is configured for npm audit --audit-level=high, Gitleaks and Semgrep p/ci, plus pull-request dependency review. Configuration is not proof that a current scan ran or passed; unresolved findings and skipped checks must remain visible.
• Dependabot updates skip Vercel deployments via vercel.json’s ignoreCommand to keep the deploy queue clean.

The public-site CSP permits inline scripts and HTTPS connections; /decision-studio has separate origin-restricted headers. These source-configured web controls are distinct from agent-worker sandbox/egress enforcement. This review inspected the configuration, not a new live deployment or successful CI security scan.

Compliance mapping

This informative crosswalk identifies evidence an accountable owner may use in a compliance program. It is incomplete and does not establish applicability, legal compliance, certification or satisfaction of any framework. Assess current jurisdiction/domain requirements, processor agreements, exceptions and operating evidence separately.

Vulnerability disclosure

Security issues in this repository should be reported per SECURITY.md: email security@contextosai.com with a description, impact, reproduction steps, and any PoC. Public disclosure is requested only after coordinated investigation. Only the latest release is supported for security updates.

Auditability

The canonical Decision Record carries the decision key/version/status, actor, evidence refs, policy decisions, approvals, active controls, budget usage, lineage, and trace_id. It can also carry tool lineage, scorecard, replay references, and optional audit hashes/signing metadata.

The originating RunContext, tool envelopes, and ReplayPacket hold related run, session, tenant, principal, transcript-chain, and side-effect-policy evidence. A replay store must preserve these as a resolvable bundle; the DecisionRecord alone is not the complete execution transcript.

This is the substrate for replay.

Incident response and replay

Replay is the primary IR primitive. Given a trace_id:

1. Resolve the pinned pack_version, snapshot, and policy bundle versions from lineage.
2. Recover the recorded invokeAgent envelope and tool transcripts.
3. Re-run deterministic stages offline and substitute recorded transcripts for external effects. Compare canonical hashes where serialization is defined and compare declared properties/scorecards for probabilistic outputs.
4. Compare the pinned baseline before separately scoring with current evaluators. A delta localizes a difference; causal attribution needs controlled comparisons, not a changed score alone.

Operational commitments:

• Quarterly drill end-to-end against a chosen production trace_id.
• Tail-based sampling retains every run that crossed a policy gate, produced a material external effect or security event, hit a loop guard, or failed scorecard thresholds.
• Time-to-replay is an operational metric; an IR contract that cannot replay within hours is treated as a regression.
• Rotation-aware verification. Replays against historical signing keys are accepted; rotation does not invalidate prior audit.

Historical verification follows the declared effective-time, revocation and key-compromise policy; retaining a key record does not make every historical signature trustworthy after compromise.

Keep live recovery separate from offline replay. Stable operation/action identity, current atomic store ownership/generation, required target fencing and six resume checks govern dispatch. A lost acknowledgement remains unknown; cancel/expire stops new work without undoing effects. Preserve original aggregate limits, reservations and verified usage across parent/child/retry/evaluator work. Re-pin of a release does not restore an external business state, and compensation is a new independently authorized operation that can fail.

Interfaces

Inputs

• Policy bundles (versioned; signed when the supply-chain profile requires it)
• Identity assertions (delegated user, agent workload, optional attestation report)
• Adapter capability declarations (with native ActionRisk, v1 approval_mode, schemas/constraints, identity and endpoint policy, idempotency/recovery contract)
• Sandbox profiles (versioned; signed when the supply-chain profile requires it)
• Run Context (tenant_id, role, claims, budgets)

Outputs

• Allow / deny verdicts with reasons and remediation hints
• Approval-gate prompts with frozen evidence
• Audit records bound to trace_id, with signatures/hash chaining when that profile is active
• Security events (cross-tenant denials, credential rotations, sandbox violations, attestation failures, A2A cycle detections)
• Replay datasets

Failure modes

• Policy drift across environments.
• Stale credentials at the Tool Gateway after a rotation.
• Revoked agent registration still discoverable by a stale A2A card or adapter cache.
• Child agent claim broader than parent claim or manifest ceiling.
• Approval gates bypassed by a Planner that skips a checkpoint (mitigated by Critic re-verify).
• Memory write that violates classification (mitigated by consent + classification check at candidate stage).
• Audit gap when a custom adapter forgets to propagate W3C trace headers (caught by trace-coverage assertion).
• Cached read-only alias hiding a permission change after a policy update.
• Indirect prompt injection from a recently-promoted memory entry that bypassed candidate-stage classification.
• Egress allow-list expressed as a tag/CNAME that resolves outside the intended origin (mitigated by DNS pinning).
• A2A receiver that accepts inbound delegation without re-attesting workload identity.
• Hash-chain truncation from a partial outage masquerading as a legitimate gap.

Operational concerns

• Policy version pinning per environment; promotion is a deliberate step.
• Secrets rotation cadence at the Tool Gateway, registry-recorded and signed when the supply-chain profile requires it.
• Workload identity rotation cadence; revoked-keys window for replay.
• Agent manifest lifecycle review and revoked-agent discovery sweeps.
• Trusted-previous-key deprecation schedule after signing-key rotation.
• Sampling stratified by native risk dimensions, policy obligations, and material effects; retain v1 tier for historical comparison.
• Trace retention bands by data classification.
• Quarterly IR drill that exercises replay end-to-end against a real trace_id.
• DNS / TLS pinning maintenance for endpoint_in[] capabilities.
• SBOM and adapter-attestation review on every adapter version bump.
• Sandbox profile re-verification on kernel upgrade.

Evaluation metrics

• Policy compliance rate (target: 100% on guardrails).
• Approval-gate honored rate (target: 100%).
• Unauthorized cross-tenant successful access (target: zero); measure denied attempts and denial-case coverage separately under an owned incident policy.
• Audit coverage (fraction of runs with full trace + manifests + decision record).
• Replay conformance rate: deterministic artifact equality plus declared property/scorecard agreement for probabilistic stages.
• Time to replay for a given trace_id.
• Mean time to detect / respond on Trust-plane events.
• Attack Success Rate on the per-intent adversarial suite (target: zero successful attacks on gated release suites; see the trusted-cloud reference).
• Redaction failure rate (target: 0% on CONFIDENTIAL / RESTRICTED classes).

Example

A condensed Trust-plane receipt on a ToolResultEnvelope:

The display uses abbreviated hashes and assumes verified payment/postcondition evidence in the linked operation artifacts. completed, redaction_applied and signer names alone are not proof of effect, masking or attestation; the v1 metadata is only a projection of the exact execution attachments.

{
  "envelope_version": "contextos.tool_result.v1",
  "tool_call_id": "tc_118",
  "run_id": "run_refund_001",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "capability_id": "adp_payments.issue_refund",
  "status": "completed",
  "output": { "transaction_id": "txn_q9", "refund_amount_inr": 4200 },
  "artifacts": [],
  "citations": [{ "evidence_ref": "policy:POLICY_RETURNS_V4#R_HIGH_VALUE_REQUIRES_APPROVAL" }],
  "mutations": ["tool:adp_payments.issue_refund:tc_118"],
  "risk_tags": ["external_state", "compensatable", "human_approved"],
  "policy_decision_id": "pol_9901",
  "metadata": {
    "approval_mode_effective": "destructive",
    "approver": "user_finance_lead_77",
    "approval_evidence_snapshot_hash": "sha256:b2a1...",
    "tool_transcript_id": "tool_tx_118",
    "redaction_applied": false,
    "chain_prev_hash": "sha256:7c4a...",
    "signed_by": "kid_runtime_2026Q2"
  },
  "latency_ms": 242
}

Common misconceptions

• Security is not a single perimeter. It is enforced at every plane boundary.
• The model is not the security boundary. Policy outside agent code is.
• Audit is not logging. The baseline is structured, correlated, replay-oriented evidence. Signing and hash chaining are stronger optional profiles that must be declared and verified.
• Sandbox is not a backup plan. It is the default for any capability that runs untrusted code.
• Prompt injection is not solved by better prompts. The defense is moving authority out of the prompt — tool surfacing, deterministic policy, arg constraints.
• A2A is not a way to launder authority. Each hop re-attests, re-evaluates, and re-records.
• Operational evidence supports compliance assessment. Typed receipts and replay material are inputs to an accountable program, not certification or proof that every legal duty is satisfied.