Agent Mesh — Security¶
Target
This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.
Identity¶
- The worker runs under a workload identity (SPIFFE-style id issued by the Authorization Server, ADR-0101) and calls the Control plane, the model gateway, the tool executor and Knowledge with it. No user credential is ever present in the worker.
- A per-attempt token is derived from the lease (tenant, project, environment, run, step, attempt, fencing token, expiry); every outbound call presents it, and the executors refuse a call whose token no longer matches the current lease holder.
- Partner and A2A callers never reach the worker; their tasks are runs submitted through the Control plane.
Authority boundaries¶
| The runtime may | The runtime may not |
|---|---|
| Load a Published release and verify it | Publish, alter or alias a release |
| Request a policy decision and an approval | Decide an approval or evaluate policy itself |
| Call models through the gateway with the pinned profile | Choose a provider or model outside the profile |
| Call tools through the executor with a decision id | Open any connection to an external system |
| Report one attempt outcome | Change run, step or attempt truth |
| Submit child runs within depth and budget | Spawn agents outside the scope of the parent run |
Side-effect classes (D21)¶
The runtime classifies nothing; the tool descriptor carries the class and the environment class may raise it (Production). Read and sandbox calls proceed; shared-write, external, production, publication and spend-above-threshold calls need a policy decision and an approval bound to the proposal hash, obtained through Run Control, and a checkpoint before the call.
Sandboxes¶
Shell, file, browser and code-execution tools run in sandboxes brokered by Execution Capacity (BC-26) and the Tools & MCP platform with filesystem and network isolation, CPU, memory and time quotas, read-only mounts, temporary credentials from the Secret Broker (BC-40) and explicit egress allow-lists (original handoff §36–38). The worker process itself has no shell, no host filesystem beyond its own store and no cloud credentials.
Prompt-injection posture¶
Model output can propose; it cannot authorize. Scope, release, policy revision, model profile and the tool closure are fixed in the snapshot; a model that proposes a tool outside the closure, a scope change or a different target environment produces a refused call recorded on the timeline. Retrieved content is tagged with its provenance and trust tier by Knowledge, and instructions found in retrieved content are not executed as instructions; the technology radar tracks guardrail and output-validation practice.
Data classification and logging (D31)¶
| Data | Classification | Handling |
|---|---|---|
| Attempt rows, call records, decision requests | confidential | hashes and references; retained per project policy |
| Adapter checkpoints | tenant data | blobs in the artifact store, encrypted at rest, deleted with the project |
| Prompts, model responses, tool payloads | tenant data | never in runtime-sql, never on spans or logs |
| Loaded releases | internal | manifests and content references |
Secrets¶
runtime-sql, the transport credential and the workload identity key live in Key Vault and are mounted through workload identity; rotation is 90 days for store and transport, 30 days for the identity key.
Audit¶
ReleaseLoadRejected, decision requests, cancellation observations and compensation starts are consumed by AuditService; every gated call is auditable through Run Control's approval and the executor's receipt.