Research Note: Trusted AI Agents in the Cloud and ContextOS

This research note maps ideas from the paper Trusted AI Agents in the Cloud onto the canonical ContextOS five-plane architecture. It treats the paper as an input to platform design, not as a replacement architecture.

The important ContextOS stance is simple: do not add a sixth plane for trusted execution. Attestation, sealed memory, policy enforcement, tamper-evident logs, and confidential compute are implementation patterns that strengthen existing ContextOS components:

• Policy Engine in the Trust plane
• Tool Manager in the Action plane
• Observability, replay, and evaluation in the Trust plane
• Memory Fabric in the Intelligence plane
• AI Gateway and LLM Router in the Decision plane model boundary

The paper’s framing is useful because it shifts attention away from prompt-only safety and toward verifiable runtime boundaries. In ContextOS terms: the model may propose, but platform services decide what context is compiled, which model route is eligible, which tool can execute, which policy applied, and which evidence is retained.

Reading stance

Use this page as a research mapping, not a benchmark claim.

The paper’s v1 threat model, revisited on 2026-10-16, assumes correct confidential-computing hardware and cryptography and trusts the measured runtime. It excludes physical, side-channel and denial-of-service attacks and assumes validated components behave according to their measurements rather than defending their subsequent compromise. Those limits are material; measurement or confidential hardware alone cannot prove an allowed action useful, an external effect complete or a deployment compliant.

• The source paper describes a trusted-agent runtime with confidential-compute isolation, attestation, policy enforcement outside agent code, tamper-evident logs, and protected long-term memory.
• The paper’s reported evaluations should be read as scenario-specific results from the authors’ setup. This note does not generalize those results or repeat numeric claims beyond the cited paper.
• ContextOS should adopt the design pressure: enforce controls at the runtime boundary, especially around MCP and A2A calls.
• ContextOS should not adopt a new canonical plane. The existing five planes already provide the right ownership model.

Five-plane mapping

Intelligence plane

The Intelligence plane owns durable meaning: ontology, identity, graph, evidence, and memory. Trusted-agent memory patterns map here.

Relevant ContextOS components and artifacts:

• Memory Fabric
• Identity Layer
• promoted memory records
• capture logs and memory candidates
• evidence refs and graph snapshots
• tenant identity and data-classification metadata
• agent registry subjects, principal chains, and run identity claims

How the research maps:

• Sealed memory becomes a high-integrity mode of the Memory Fabric, not a separate store that bypasses promotion.
• Encrypted entries, freshness checks, and rollback detection can protect capture logs and episodic/action memory.
• Promotion rules still apply. A protected capture is not automatically reusable context.
• Redaction, retention, deletion workflows, and tenant policy remain part of the memory contract.

Context plane

The Context plane compiles bounded state for one request. Trusted-agent patterns map to manifests, pinned inputs, and runtime controls.

Relevant ContextOS components and artifacts:

• ContextPack
• CompiledContext
• policy manifest
• tool manifest
• evidence manifest
• runtime controls

How the research maps:

• Attestation inputs should be represented as manifest references: pack version, policy bundle hashes, tool manifest hashes, model profile, graph snapshot, and memory snapshot refs.
• The compiler should expose only eligible tools and policies to the Decision plane.
• Confidential-compute state can be an input to compilation when a workflow requires a specific runtime profile.
• The prompt remains an output of compilation. It is not the security boundary.

Decision plane

The Decision plane owns planning, critique, execution flow, model routing, and DecisionRecord production. Trusted-agent patterns map to bounded execution and auditable route decisions.

Relevant ContextOS components and artifacts:

• Planner / Executor / Critic
• AI Gateway and LLM Router
• DecisionRecord
• model profile
• route decision
• replay packet

How the research maps:

• Model calls should continue to cross the AI Gateway, where provider selection, redaction, residency, cost budgets, telemetry, and route audit are enforced.
• A model-native tool-call proposal is still only a proposal. External effects return to the Executor and cross the Tool Manager.
• Per-run receipts should bind the request, compiled context reference, model route, policy decisions, tool results, and output digest.
• The Decision plane should receive structured denials and obligations from policy checks so it can re-plan, ask for approval, or refuse.

Action plane

The Action plane owns side effects through the Tool Gateway pattern. Trusted-agent policy enforcement maps most directly here.

Relevant ContextOS components and artifacts:

• Tool Manager
• MCP adapters
• A2A adapters
• ToolEnvelope
• idempotency keys
• delegated user identity and agent workload identity

How the research maps:

• MCP and A2A calls must be mediated by the Tool Manager.
• Tool discovery does not authorize execution. Registered capabilities, schemas, native action risk, the conservative v1 mode projection, identity, evidence, and policy decisions determine eligibility.
• Policy enforcement belongs outside model and agent code.
• A2A handoff must mint a fresh narrower child identity claim. Passing along a parent bearer token or accepting a broader child scope is a privilege escalation.
• Confidential-compute isolation can harden high-risk agent workers or adapters, but it does not replace Tool Manager mediation.
• Every write-class action should carry an idempotency key, policy decision ref, trace context, actor identity, and result audit metadata.

Trust plane

The Trust plane owns policy, identity, approvals, evaluation, observability, replay, and improvement gates. Trusted-agent verification maps here.

Relevant ContextOS components and artifacts:

• Policy Engine
• approval gates
• Observability
• evaluator results
• replay harness
• policy bundle registry
• audit and evidence stores

How the research maps:

• Policy remains a deterministic boundary outside model code.
• Tamper-evident logs belong in Observability and the Decision Catalog, indexed by trace ID and DecisionRecord.
• Attestation evidence should be persisted as audit metadata and replay inputs.
• Evaluation suites should include adversarial MCP/A2A scenarios such as data exfiltration attempts, excessive tool invocation, unauthorized resource access, privilege escalation, and execution-flow disruption.
• Confidential-compute attestation can become a policy condition for high-risk actions.

Research concept mapping

Attestation

Attestation is a way to make “what ran where, under which inputs and policies” verifiable across principals. In ContextOS it should be represented as evidence attached to existing runtime artifacts.

Map it to:

• Trust plane: attestation verifier, policy conditions, approval evidence
• Observability: span attributes, audit events, receipt storage
• Decision plane: route decisions, DecisionRecord, replay packet
• AI Gateway: model profile and provider-route evidence
• Tool Manager: adapter identity, tool capability, execution environment evidence

A ContextOS execution receipt can include:

{
  "receipt_id": "rcpt_01j9",
  "run_id": "run_88",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "compiled_context_ref": "compiled_ctx_41",
  "policy_bundle_refs": ["policy_bundle:refunds:v7"],
  "model_profile_ref": "model_profile:standard:2026-05-09",
  "tool_manifest_ref": "tool_manifest:support:v3",
  "runtime_profile_ref": "runtime_profile:confidential-worker:v2",
  "input_digest": "sha256:...",
  "output_digest": "sha256:...",
  "nonce": "..."
}

This is an illustrative deployment receipt, not a new base schema. Verify its publisher/trust root, measurements, nonce/freshness and complete artifact/input/output binding before relying on it. Short hashes are display placeholders. The receipt cannot establish model correctness, current business authority or downstream completion merely by naming a known runtime.

Policy enforcement

The paper emphasizes policy enforcement outside agent context. ContextOS already has this ownership split: the Policy Engine decides, and the Tool Manager enforces at execution time.

Map it to:

• Trust plane: rule evaluation, native action-risk checks, v1 approval projection, obligations, and denials
• Context plane: policy bundle selection and runtime controls
• Decision plane: structured denial handling and re-planning
• Action plane: execute-time re-check before every external effect
• AI Gateway: model-route policy, provider eligibility, budget and residency controls

ContextOS can use different policy backends where appropriate, but the boundary should preserve structured policy decisions and the fields recorded in DecisionRecord. If OPA/Rego is used, it is an implementation backend, not a replacement for the ContextOS policy contract.

Policy checks should cover:

• endpoint and capability eligibility
• function and argument constraints
• tenant and actor authorization
• native action-risk constraints and the v1 approval projection
• call budgets and repeated invocation limits
• data classification and residency
• required evidence before the effects selected by DecisionSpec and policy; network transport alone does not imply approval

Provenance and tamper-evident logging

Tamper-evident logging turns runtime behavior into evidence that can be reviewed and replayed. It does not mean every raw log should be retained forever or exposed without redaction.

Evidence supports accountable compliance assessment; it does not automatically satisfy domain law or certify the runtime. Refs/hashes, sealed records, telemetry and exported packets still need actual purpose/reader/processor and retention/copy policy.

Map it to:

• Observability: OTEL traces, audit events, policy decision events, action spans
• Decision Catalog: durable DecisionRecord index
• Tool Manager: tool transcripts and result metadata
• AI Gateway: route decision records
• Memory Fabric: action-memory capture, after retention and redaction checks

Implementation patterns:

• hash-chain important run events
• sign or seal exported audit packets
• persist policy_decision_id, trace_id, run_id, decision_key, and artifact refs together
• keep raw secrets and sensitive payloads out of general-purpose traces
• make replay packets content-addressed and version-pinned

Sealed memory

Sealed memory is best understood as protected memory infrastructure, not as a new memory model. ContextOS memory remains promotion-aware.

Map it to:

• Memory Fabric capture log
• episodic/action memory
• promotion review queue
• evidence refs and source manifests
• tenant-scoped encryption and deletion workflows

Implementation patterns:

• encrypt memory entries with tenant-scoped keys
• store integrity metadata with capture events
• detect rollback or freshness regressions where platform support exists
• attach policy decision and approval refs to action memories
• require promotion before captured data can become compiled future context

Sealed memory should preserve auditability without turning all past observations into future authority.

Confidential compute

Confidential compute can reduce trust placed in the cloud host for selected workloads. It is a deployment profile and evidence source, not a replacement for ContextOS policy, identity, or observability.

Map it to:

• deployment blueprint: runtime profiles for high-risk workloads
• Trust plane: attestation verifier and policy condition
• Action plane: confidential Tool Manager workers or adapters for sensitive effects
• Decision plane: confidential model-routing workers where required
• AI Gateway: provider and runtime eligibility checks
• Observability: attestation status and runtime profile refs in spans

Use it selectively:

• high-risk workflows with sensitive inputs or regulated effects
• adapter execution that handles privileged credentials
• tenant requirements that demand attested workloads
• replay or audit scenarios where runtime provenance matters

Require it when the admitted workflow’s threat model calls for it. Deterministic boundaries, typed artifacts and replayable evidence remain required independently of that infrastructure choice.

The current Execution Contract makes this mapping concrete without adding a plane: exact profile/feature admission, current observed boundary/configuration, complete action/stored approval binding, actual data-flow/memory lifecycle policy, stable operation/checkpoint recovery and shared aggregate reservations. A cryptographic infrastructure profile may provide evidence for some obligations; it cannot replace the remaining controls or the useful/denied/current-runtime evidence required for an exact workflow/release/environment claim.

Governed MCP/A2A flow

The safe path is a composed ContextOS run, not a direct agent-to-tool shortcut:

1. The request enters with a RunContext.
2. The Context plane compiles eligible evidence, tools, policies, memory, and runtime controls.
3. The Decision plane plans and critiques the next step.
4. The AI Gateway handles model calls and emits route evidence.
5. The Executor proposes a tool or A2A action.
6. The Tool Manager validates schema, identity, idempotency, and capability.
7. The Policy Engine evaluates the current action context.
8. Approval gates run when policy emits an approval obligation for the concrete native risk and call context.
9. The adapter executes only after the boundary allows it.
10. Observability records trace spans, policy decisions, route decisions, tool results, and receipt refs.
11. The Decision plane emits a DecisionRecord and replay packet.
12. Memory Fabric captures eligible action memory as a candidate, not an automatic promoted memory.

Before protected dispatch, recheck current authority/revocation, exact stored approval and atomic redemption, required active containment/data route and original budget reservation. Retain stable operation identity and confirmed/partial/unknown effect evidence across timeout, child cancellation and fenced resume. Provider-specific retry safety and separately governed compensation remain necessary even inside an attested runtime; sealed checkpoints cannot reset capacity or turn uncertainty into absence.

Denied actions should be first-class outputs. They should produce a policy decision, a trace event, and a structured reason that the Executor can use to re-plan or escalate.

Minimum implementation checklist

For ContextOS builders, the useful research-to-product translation is this checklist:

• Keep the Policy Engine outside model and agent code.
• Require every external effect to cross the Tool Manager.
• Give every agent a versioned registry subject (agent:contextos/<slug>@<version>), structured owner, lifecycle, and manifest scope ceiling.
• Where the identity profile is adopted, attach short-lived claims to governed runs and A2A hops, require signatures when its attestation policy calls for them, and audit claim hashes rather than raw secrets.
• Reject revoked agents, expired claims, tenant mismatches, and child claims broader than their parent.
• Add policy-decision refs to every ToolEnvelope.
• Add model-route refs to every AI Gateway response.
• Persist attestation and runtime-profile refs where a workflow requires them.
• Hash-chain or otherwise integrity-protect material run events in Observability.
• Index evidence through the DecisionRecord, not scattered logs.
• Treat sealed memory as a Memory Fabric storage and integrity mode.
• Compile future context only from promoted memory and current evidence refs.
• Include adversarial MCP/A2A suites in the evaluator harness.

Design limits

These patterns reduce ambiguity at runtime, but they do not remove all risk.

• Attestation proves properties about measured software and runtime state; it does not prove the model’s answer is correct.
• Policy enforcement can block disallowed actions; it does not make allowed actions useful or harmless.
• Tamper-evident logs improve auditability; they still need retention, redaction, and access-control policy.
• Sealed memory can protect stored records; it still needs promotion controls and deletion workflows.
• Confidential compute can reduce host-trust assumptions; it does not replace identity, approval gates, or replay.

Appendix: canonical attack classes to include in ContextOS evaluation

Use these as evaluator categories, not as a promise that any one control eliminates the class.

• data exfiltration through tool arguments, files, memory recall, or messages
• excessive or repeated tool invocation against write-class capabilities
• unauthorized resource access across tenant, project, role, or classification boundaries
• privilege escalation through delegated identity, adapter credentials, or A2A handoff
• execution-flow disruption that tries to skip critique, approval, logging, or replay capture
• policy-confusion cases where a tool is discovered but not eligible for the current actor or context

The metric should be scenario-specific and tied to a named adversarial suite. Avoid publishing global success-rate claims unless the suite, baseline, controls, and source data are all explicit.

The ContextOS design takeaway is therefore architectural, not magical: trusted-agent research strengthens the existing five planes when its primitives are mapped to the components that already own policy, action mediation, observability, memory, and model routing.