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 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, approval modes, identity, 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": "..."
}

The receipt should not claim the model reasoned correctly. It should claim that a known runtime handled a known request under known artifacts and emitted a known output.

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, approval-mode escalation, obligations, 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 platform contract should remain the typed PolicyDecision envelope. 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
• approval-mode requirements
• call budgets and repeated invocation limits
• data classification and residency
• required evidence before network, delegated, or destructive actions

Provenance and tamper-evident logging: compliance as a byproduct, not a project

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.

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

Do not require it for every ContextOS deployment path. Most governance value still comes from deterministic boundaries, typed artifacts, and replayable evidence.

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 the effective approval mode requires them.
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.

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.
• Attach short-lived signed identity claims to governed runs and A2A hops; 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.