SCHEMATIC ID: DS-ARCH-COMPOSITION-V1 · AGENT GOVERNANCE CONTROL PLANE
System Composition — Agent Governance Control Plane
8 independently deployable systems + 3 globally unique contracts
How to read this
This document is organised by system, not by feature. Each system is described in four terms: what it exclusively owns (no other system can do it for you), which internal modules it consists of, where it is deployed, and what breaks if you split it. §4 gives you the whole picture; §5 is the detail drawing for each system.
Section 00 — Thesis
In one sentence
An Agent Governance Control Plane consists of 8 independently deployable systems and 3 globally unique contracts. It does not replace your agents, models or business systems. It sits between the agent and everything the agent reaches — models, tools, data, downstream systems — and closes the loop: see it · control it · contain it · prove it · verify it.
Core Abstraction
The object of governance is not "the agent as a principal". It is "one execution of the agent".
Treating an agent as a principal to be authorised — like a user, like a service account — is traditional IAM thinking carried over unchanged. A principal only answers who. But cascading failure and memory poisoning do not exist inside any single call; they exist only in how the execution unfolds.
The correct first-class object is the Trajectory: the complete causal structure of one agent execution, from initiation to termination. Every system in this architecture is defined by its role around it — policy adjudicates on it, audit is derived from it, evaluation scores it, anomalies are detected on it.
Blueprint ID: GOV-COMP-THESIS-V1Sheet 01 / 12
Section 01 — Target Audience
Who this is for
Organisations that already run — or are building — business agents, and now need to close the loop on seeing / controlling / proving / verifying. Three situations in particular:
| Situation | Typical setting |
|---|---|
| Staff already use Claude Code / Cursor / desktop AI, but the company has no idea how many, or which MCP servers they are connected to | Engineering-heavy tech companies, fintech |
| An in-house agent platform works for the business, but after an incident nobody can establish accountability, and regulator questions go unanswered | Finance, public sector, regulated industries |
| Agents are about to touch production writes — refunds, orders, deployments, config changes — where the risk is irreversible | Trading, payments, SRE, supply chain |
Blueprint ID: GOV-COMP-AUDIENCE-V1Sheet 02 / 12
Section 02 — Positioning
Positioning
| Dimension | Description |
|---|---|
| What it is | A governance plane that escorts business agents — it is not itself a business agent |
| Core problem | In a system where principals are ephemeral, behaviour is non-deterministic, permissions are dynamic and responsibility is multi-hop, how do you stay attributable, constrainable and provable? |
| Relationship to agent platforms | Decoupled. Supports in-house agents, open-source frameworks, third-party agents (Claude Code / Cursor / Copilot …) and managed runtimes |
| Onboarding model | Tiered admission L0–L3: from "install a probe and be discovered" to "signed events + cross-corroboration, therefore provable". Onboarding cost and assurance strength are priced against each other |
| What it does not do | Does not require migrating your agent runtime, does not require rewriting downstream authorisation code, does not lock you into one audit backend or one cloud |
Blueprint ID: GOV-COMP-POSITION-V1Sheet 03 / 12
Section 03 — Problems Solved
The seven problems
| Problem | How it shows up | Which system answers it |
|---|---|---|
| You cannot see it | Claude Code on a laptop, local stdio MCP, A2A inside the same pod — none of it leaves the network, so the gateway never sees it | Probe (factual channel) + Registry (shadow discovery, cataloguing, AI-BOM) |
| Every step is compliant, the sequence is not | Each step is individually within permissions; strung together they become cascading failure, infinite loops, goal drift | Policy: the adjudication input is "trajectory + current step", not a single call |
| No accountability after an incident | Human → orchestrator agent → sub-agent → tool → resource. Reconstructing this from logs afterwards is inherently ambiguous | Identity (delegation chain travels with the credential, not as a side log) + Audit (causal DAG assembly) |
| The agent's own account is not evidence | After prompt injection or a supply-chain compromise, the SDK instrumentation itself can be rewritten | Probe three-channel collection + Audit cross-corroboration + daemon signing (private key unreadable by the agent) |
| Long-lived credentials are scattered | API keys and AK/SK live in code, environment variables and prompts; rotation is manual | Identity vault custody + injection at the Gateway; the agent process never sees plaintext |
| High-risk actions rely on the prompt | Refunds, transfers, resource deletion, deployment — held back by prompt wording and guardrails, and still bypassable | Policy approval gate + Portal approval workbench (the approver signs an immutable action digest) |
| Nobody checks whether it is doing the job right | Release is gated by manual spot-checks; quality regressions after a model version change go unnoticed | Eval: quality score as a release gate + multi-turn red teaming + evaluator isolation |
Blueprint ID: GOV-COMP-CHALLENGE-V1Sheet 04 / 12
Section 04 — System Composition
Composition: 8 systems + 3 contracts
The split follows trust boundaries and deployment boundaries — not the org chart. Each system has its own name, interface and delivery boundary, and can be taken out on its own when needed; otherwise it stays behind the platform.
4.1 The eight systems
| # | System | Exclusive responsibility (nothing else can do it) | Deployment |
|---|---|---|---|
| S1 | Agent Portal | Produces the first hop of the delegation chain — this is the only place a real human identity exists | Central, one per organisation |
| S2 | Agent Registry | The single source of truth for "what exists and what each thing can do", and a hot-path data source for policy | Central + local cache at each PEP (change push ≤ 30s) |
| S3 | Agent Identity | Issues verifiable identities and delegation chains, and guarantees monotonic narrowing at every hop | Central issuance + node-side Workload API (UDS / vsock) |
| S4 | Agent Gateway | The only non-bypassable enforcement point — downstream accepts calls only from the gateway | Central or per-zone, mandatory routing |
| S5 | Agent Policy | Adjudicates, and emits decision_reason (why it was allowed or denied) | Central PDP + edge fast-path cache |
| S6 | Agent Probe | Provides factual observation and event signing that does not depend on the agent's cooperation | Distributed with the agent: in-process SDK + host daemon + kernel |
| S7 | Agent Audit | Assembles trajectories, cross-corroborates, and produces independently verifiable evidence | Central, WORM + hash-chain storage |
| S8 | Agent Eval | Turns "is it doing the job right" into a release gate | Central, and fully isolated from the agent under evaluation |
4.2 The three contracts
Non-negotiable
Contracts do not get split. This is the one prerequisite for the eight systems fitting together at all.
| Contract | Content | Produced by | Consumed by |
|---|---|---|---|
Audit eventAuditEvent |
Five field groups: identity & authorisation / causality / action / decision / linkage & provenance. decision_reason and collector+confidence are mandatory |
S1 S4 S5 S6 | S7 S8 |
Capability declarationCapabilityDeclaration |
Tools (down to method and argument level) · externally writable content sources it reads (the indirect-injection surface) · writable resources · sub-agents · memory scopes · actions requiring approval · models and egress boundary | Submitted at registration | S2 admission / S5 default policy / S7 comparison / S8 evaluation |
Delegation chainDelegationChain |
RFC 8693 Token Exchange with an authorisation server as broker; user_identity / agent_identity / delegation_chain / scope / audience / resource / expiry / trace_id, plus jti · nonce · confirmation key · chain-length limit · revocation |
S1 first hop, S3 issuance | S3 S4 S5 verify end-to-end |
Contract Discipline
These three schemas are globally unique. No system may define its own variant. You can roll systems out in phases, you can buy only some of them — but the moment the contracts fork, trajectories cannot be assembled, delegation chains cannot be verified, and evidence cannot be reconciled. This is the one line that no split may cross.
4.3 System topology
Execution path / events (trajectory)
Control plane (identity · decision · query)
Untrusted subject / human action
FIG. 4.3 — SYSTEM TOPOLOGY · 8 SYSTEMS
Blueprint ID: GOV-COMP-TOPOLOGY-V1Sheet 05 / 12
Section 05 — System Breakdown
System by system
S1Agent Portal
The single entry point and approval desk through which staff and business users reach agents.
| Internal module | Responsibility |
|---|---|
| Identity onboarding | SSO federation: OIDC / SAML / SCIM against your existing IdP; a managed UserPool is also available |
| Application catalogue | A permission-trimmed agent list — users only see the agents they are allowed to see |
| Session and intent | Records the original intent as the root of the trajectory; keeps the session on record |
| Approval workbench | Human-in-the-loop interaction and record. The approver signs an immutable action digest, checked for equality at execution time — this is what prevents "approve A, execute B" |
| Inbound PEP | Verifies admission level, delegation chain and capability declaration before letting the call through |
Exclusive Responsibility
The first hop of the delegation chain can only be produced here. A call that did not pass through the Portal has an empty
human_initiator — and that is itself a policy predicate, not missing data.
Standalone value: even with no governance at all, this is the answer to "how do we give employees one way into enterprise AI applications" — single sign-on, application catalogue, approval workbench, session records.
S2Agent Registry
Which agents, tools, MCP servers and models exist in the organisation, and what each of them can do.
| Internal module | Responsibility |
|---|---|
| Object registration | AgentBlueprint · Tool · MCP server · Model · Skill · sub-agent endpoints |
| Two-layer model | Blueprint / Instance: governance acts on the blueprint, execution happens in the instance. Policy is attached to the blueprint and inherited automatically, so one action can stop an entire class |
| Declaration validation | Checks the declaration is self-consistent at registration (referenced tools exist, argument constraints are syntactically valid) + indirect-injection surface analysis (which externally writable content sources it reads) |
| Admission level | admission_level L0–L3 stored and used as a policy input: "anything below L2 may not touch resource class X" becomes an expressible policy |
| Bill of materials | Emits an AI-BOM (CycloneDX ML-BOM extension) for vulnerability blast-radius analysis |
| State machine | draft → active → quarantined → retired. Quarantine preserves the evidence while cutting off capability — it is not deletion |
| Visible-tool trimming | Permission-trimmed tool set + semantic search — the agent only sees the tools it is allowed to see, rather than exposing everything and intercepting afterwards |
| Neutral meta-model | Third-party agents (Copilot / Agentforce / Claude Code …) normalised into a common attribute model |
| Hot-path service | Separated from management-plane queries: local cache + change push (≤ 30s) |
| Liveness | Heartbeat-based online/offline detection, alerting on offline; the state feeds into policy |
Exclusive Responsibility
It is first a policy data source (runtime hot path, strongly consistent, low latency) and only second a discovery catalogue or reusable asset inventory. Get that ordering backwards and you build a slow asset ledger.
Interface: Register / Update / Deprecate / Query(hot-path) / ExportBOM. The Registry itself is exposed as an MCP server — humans and agents use the same discovery path.
S3Agent Identity
Issues verifiable identities to agents, manages delegation chains and credentials, and keeps long-lived secrets out of agent code.
| Internal module | Responsibility |
|---|---|
| Identity issuance | Two-level SPIFFE SVIDs: one SPIFFE ID for the blueprint, one for the instance. K8s → UDS mount; bare process → local UDS; microVM → Workload API bridged over vsock |
| Chain issuance and verification | JWT-SVID inside the organisation; token exchange (ID-JAG shape) across applications. Monotonic narrowing (scope[i+1] ⊆ scope[i]) checked at issuance and re-checked at verification |
| Holder binding | DPoP-style binding to the holder's key, so a leaked token cannot be replayed laterally |
| Environment attestation | At issuance, verifies that code, image and runtime environment match the registration, preventing identity cloning |
| Credential vault | OAuth 2.0 (2LO / 3LO) · API key / AK-SK · STS short-lived tickets under one custody. Long-lived credentials never leave the vault; they are injected at the gateway, and the agent process never sees plaintext |
| Revocation and expiry | Permissions granted as time-boxed "access packages" that expire automatically; when a user revokes consent, the corresponding access dies with it |
| Signing service | Private keys stay in KMS / TPM, and every signature produces an audit record. The probe daemon's signing key derives from here and is unreadable by the agent process |
| Risk scoring | Two sources: derived from the associated human identity's risk, plus the agent's own behavioural anomalies. High risk affects discoverability in the Registry, not merely request denial |
Exclusive Responsibility
Identity issuance and delegation-chain verification must live in the same system. Split them and nobody guarantees monotonic narrowing — the chain can be forged or widened.
Target state: eliminate static API keys. Existing ones move to vault custody with automatic rotation as a transition.
S4Agent Gateway
The mandatory channel for every outbound call an agent makes.
| Internal module | Responsibility |
|---|---|
| Egress model gateway | Routing, cost attribution, rate limiting, content guardrails |
| MCP / A2A broker | MCP and A2A are two separate control channels, not one shared policy surface |
| Inbound gateway | Admission before an agent is invoked: verifies level, delegation chain, capability declaration |
| Payload parsing | Policy granularity down to tool + method + arguments, which requires parsing the MCP message body |
| Credential injection proxy | Exchanges for short-lived credentials at S3 according to this action's decision and proxies the downstream call; the agent never touches plaintext |
| Content guardrails | Covers all four object classes: prompt / response / agent action / MCP interaction. PII is redacted before it reaches the model, and re-checked on egress |
| Rate limiting and breakers | Dimension (JWT claim / principal / target / tool / model) × measure (RPS · TPM · connections) × most-specific-wins × rate=0 emergency block × two-tier ceilings that only narrow |
| Boundary-channel events | Emits call target, method name, payload size and data destination — one of the high-confidence channels |
Exclusive Responsibility
It is the only non-bypassable enforcement point. The way that is realised: downstream accepts calls only from the gateway (source identity check / workload allowlist) and rejects everything else.
Engineering Note · A2A
A Signed Agent Card only guarantees the integrity of the card and the origin of its claims. It does not prove which instance the current connection belongs to. Transport identity, message authorisation, nonce, audience and replay protection must be configured separately. Treating it as proof of identity leaves a real gap.
Standalone value: cost attribution, routing, guardrails and rate limiting for model traffic — the egress half is deliverable on its own.
S5Agent Policy
The single adjudication brain (PDP) that every enforcement point asks.
| Internal module | Responsibility |
|---|---|
| PDP | Outside the reasoning loop — a constraint that can be talked out of by a prompt is not a constraint |
| Adjudication input | (trajectory so far, current step, capability declaration, agent identity, delegation chain, the user's own permissions) |
| Triple check | Downstream must satisfy all three: the agent has permission + the user has permission + the user explicitly delegated it — this is what closes the confused-deputy hole |
| Trajectory feature service | Pre-computed feature families so the PDP never aggregates inline: cumulative_impact · no_progress_rounds · distinct_resources_touched · data_egress_bytes |
| Dual mode | dry_run (log only, no block) and enforce. The factory default is dry_run; blocking requires an explicit switch to enforce |
| Approval gate | The criterion is "would a human judgement materially change the outcome", not a simple risk-tier cut-off |
| Trajectory-level detection | Loop detection (repeat-call counts / no-progress rounds / budget breakers) · sequence-level intent anomalies |
| Kill-switch | Three levels: single instance / whole blueprint / global. Target effect ≤ 5s, implemented as credential revocation + rate=0 + PEP denial in combination |
| Reverse validation | Periodically replays known should-deny samples to confirm the policy actually stops them |
| Decision record | Emits decision_reason — recording "blocked" without "why" leaves the most important question unanswerable in a post-incident review |
Exclusive Responsibility
PDP adjudication and
decision_reason emission cannot be separated.
Design Requirement · policy language must be two-layered
No single policy language solves this. Layer one must be able to statically decide permits-more-than — that is the precondition for proving monotonic narrowing (
scope[i+1] ⊆ scope[i]) of the delegation chain. A Turing-complete policy language (Rego, for example) cannot decide that property in general; a decidable language such as Cedar can. Layer two is the pre-computed trajectory features: a decidable language cannot express trajectory-level aggregation, so a feature service must compute it outside the PDP and feed it in. Whatever you choose, keep a custom PDP extension point.
Enforcement layout: one PDP, three PEPs — inbound (Portal) · egress (Gateway) · in-process (Probe / runtime).
S6Agent Probe
The three-layer collection substrate — SDK + daemon + kernel.
| Channel | Technology | What it captures | Confidence |
|---|---|---|---|
| Semantic | Thin multi-language clients (Go / Py / Node / Java / Rust) over a local UDS | Prompts, tool names and arguments, delegation chain, memory reads/writes, sub-agent dispatch | Low runs inside an untrusted subject |
| Factual | Linux eBPF; Windows ETW (+ minifilter / WFP driver); macOS EndpointSecurity | exec, file reads/writes, connect, DNS, TLS SNI | High |
| Boundary | Emitted by the S4 Gateway (not part of the probe) | Call target, method name, payload size, data destination | High |
The local daemon: how this works across languages
- A Rust core runs as a sidecar or host daemon; the per-language SDKs are thin clients (serialise + UDS) holding no keys and no delivery logic
- The daemon owns: unified event model, local pre-correlation, signing, buffering and backpressure, batched idempotent upload
- The signing key comes from a SPIFFE SVID / TPM and is unreadable by the agent process — this is the technical precondition for provability
- Spools to disk when the network is down; fully offline environments support manual forensic export
- No FFI: FFI means maintaining a build matrix and ABI compatibility per language; the daemon approach also answers "who attaches eBPF"
Exclusive Responsibility
It provides an observation channel that does not depend on the governed agent's cooperation. It is also the only way shadow agents are found — an un-onboarded Claude Code or a local stdio MCP server is visible from nowhere else.
Structural Ceiling
Cross-corroboration only applies to actions with externally observable side effects (network, file, exec). In-process memory reads and writes, the reasoning behind tool selection, and prompt construction have no second observation channel and will always be self-asserted. So for memory poisoning, what is achievable is "memory access is completely recorded and non-repudiable" — not "memory contents are trustworthy". This is a structural ceiling rather than a coverage gap: any solution claiming the latter deserves the question "where is the second observation channel?"
Standalone value: deliverable purely as a data source, feeding agent behaviour into an existing SIEM or data lake.
S7Agent Audit
What actually happened during one execution, and being able to say so when it matters.
| Internal module | Responsibility |
|---|---|
| Ingest layer | Receives all three channels, validates against the schema, persists |
| Trajectory assembly | A causal DAG built from causal_parents (multi-parent), not a time series; supports forks (sub-agent dispatch) and joins (async merge) |
| Cross-corroboration | Correlation anchors (pid, fd, time window, target 5-tuple, payload fingerprint). Three channels agree → accept with high confidence; self-asserted but not factual → the SDK may have been tampered with; factual but not self-asserted → a side channel exists |
| Two separated projections | The audit projection (unsampled, long-lived, WORM + hash chain) and the observability projection (sampled, short-lived, time-series store) must be kept apart |
| Tiered storage | An immutable envelope (metadata + digest + signature) separated from the sensitive payload; the envelope is append-only, the payload has its own lifecycle |
| Privacy and erasure | By default only digests / classifications / references are stored; payloads are encrypted per tenant key and, on expiry or a subject request, the key is destroyed (crypto-erasure) while the envelope and hash chain stay intact |
| Secret detection | Scans for credentials / keys / tokens before persistence, quarantining and alerting on hits — the audit store must not become a new leak source |
| Read auditing | Queries against the audit store are themselves recorded; audit read permission is independent of business permission |
| Evidence packages | An evidence package is verifiable independently of this system, detecting modification, deletion, insertion, reordering and truncation |
| Compliance packs | One-click generation of filing / assessment material: model inventory, corpus provenance, security measures, evaluation records |
| Topic clustering | Hierarchical clustering of "what people are actually using it for", surfacing quality regressions |
| Pluggable backend | ClickHouse / ES / your choice; OTLP export means an existing SIEM can be fed directly |
Exclusive Responsibility
Trajectory assembly and cross-corroboration must happen in the same place. Reconciliation requires all three channels assembled together; split them and there is nothing to compare.
On OpenTelemetry: three separate decisions, not one
| Layer | Choice | Reason |
|---|---|---|
| Propagation W3C Trace Context | Required: accept an inbound traceparent, pass it through on egress, and propagate to MCP targets via _meta | Without it the chain breaks at every system boundary |
| Semantic conventions OTel GenAI semconv | Required (through a mapping layer; the internal contract stays ours) | Major vendors have all aligned; Claude Code already emits OTel GenAI traces, so alignment means direct consumption |
| Backend Jaeger / Tempo / commercial APM | Optional: storage and query built in, with OTLP export available | Nobody should have to stand up a tracing backend before they can debug |
Common Mistake
Bringing your own storage is not the same as inventing your own format. The common error is to collapse all three decisions into one: "we don't want to depend on an external tracing backend" is a sound product judgement, but it does not imply "don't use the OTel format", and it certainly does not imply "don't stitch traces across systems".
One clarification:
One clarification:
traceparent is a correlation mechanism, not an authorisation credential — evidence always rests on signed events. Across trust domains, use links rather than parent inheritance, and have a trusted entry point issue an independent governance_execution_id.
S8Agent Eval
Is the agent doing the job right, and may it ship?
| Internal module | Responsibility |
|---|---|
| Metrics | Journey completion · answer relevance · answer correctness · tool selection accuracy and tool argument accuracy (measured separately) · instruction adherence · goal attainment |
| Release gate | Quality score below threshold → release blocked, structurally identical to a code-quality gate |
| Drill-down | Evaluation results are bound to the trajectory as events, so a score drills down to the specific trajectory |
| Red teaming | Multi-turn — single-turn testing gives false assurance |
| Policy loop | Red team / evaluation produces candidate policies → replay validation → human sign-off → phased dry-run → enforce. Nothing goes from an evaluation result straight to production enforce |
| Online evaluation | Sampled online evaluation of production traffic, monitoring metric drift |
Exclusive Responsibility · evaluator isolation
Berkeley RDI (April 2026) used a single attacking agent to drive eight mainstream agent benchmarks to near-perfect scores — zero tasks solved, and in most scenarios zero LLM calls. The method was attacking the evaluation pipeline itself. Any "quality score as release gate" therefore carries three hard requirements:
| # | Requirement |
|---|---|
| 1 | Evaluator isolation: execution, judgement and scoring must not run anywhere the agent under evaluation can read, write or inject; the result write path must be unreachable from it |
| 2 | The gate cannot be self-certified: the quality score is produced and signed by a party independent of the agent (same daemon signing model — the evaluated party never holds the private key) |
| 3 | Private eval sets are primary: public benchmarks are reference only, never the gate. The gate uses a private set drawn from the production task distribution, treated as evidence and kept out of any agent-readable context |
Division of Labour
Anything decidable is checked by deterministic code, never by an LLM judge. Whether a tool is inside the capability declaration, whether arguments satisfy their constraints, whether a call exceeds authority — all decidable. Handing those to an LLM judge is both expensive and unreliable (length, position and self-preference bias, plus non-determinism), and it turns a gate into a probability. LLM judges are for semantic judgement only, and then only with a structured rubric, repeated judgements and calibration against human labels.
Blueprint ID: GOV-COMP-SYSTEMS-V1Sheet 06 / 12
Section 06 — Cross-cutting Capabilities
Two cross-cutting capabilities
Two things are production admission requirements yet belong to none of the eight systems alone. If they are not explicitly assigned, they fall through the cracks.
6.1 Recovery and compensation
Principle
If a constraint fails to prevent an action, it must be possible to undo the consequence. For agents that touch databases, refunds, deployments or resource deletion, this is a production admission requirement, not a nice-to-have.
| Capability | Which system carries it |
|---|---|
| Classification of irreversible actions; registration of the compensating action | S2 Registry (recorded at declaration time) |
| Irreversible actions forced to human escalation, never autonomous | S5 Policy |
| High-impact actions produce a diff / blast-radius preview first | S1 Portal (for the approver to judge) |
| Approval bound to an immutable action digest, checked for equality at execution | S1 Portal issues → S4 Gateway verifies |
| Idempotency keys: a replay produces no second side effect | S4 Gateway injects and deduplicates |
| Transaction boundaries and partial-failure handling | S7 Audit records, S5 Policy decides |
6.2 Data governance
Principle
Audit demands "complete and undeletable"; privacy law demands "deletable and minimised". Both must hold at once — writing down only the first half is not an answer.
| Capability | Which system carries it |
|---|---|
| Envelope / payload tiering, crypto-erasure, retention and legal hold | S7 Audit |
| PII redaction before the model, re-check on egress | S4 Gateway |
| Secret detection and quarantine before persistence | S6 Probe (local pre-scan) + S7 Audit (pre-persistence) |
| Tenant keys, data residency | S3 Identity (keys) + S7 Audit (residency) |
| Data-subject rights: what can be honoured (payload destruction) and what cannot (non-repudiable metadata) | S7 Audit, with the legal basis stated |
Blueprint ID: GOV-COMP-CROSSCUT-V1Sheet 07 / 12
Section 07 — Runtime Sequence
One execution, system by system
| Stage | S1 Portal | S4 Gateway | Agent runtime | S6 Probe |
|---|---|---|---|---|
| ① Initiate | Human authentication → first hop; trajectory rooted; original intent recorded | Inbound admission: verify level and chain | Instance derived from blueprint | Process fingerprint into the trajectory |
| ② Reason | — | — | Reasoning steps recorded | — |
| ③ Tool call | — | S5 adjudicates + intercepts; exchanges short-lived credentials at S3; records target and data destination | Tool selection and arguments recorded | Kernel records connect / file / exec |
| ④ Memory I/O | — | Recorded if it goes to remote storage | Scope and keys recorded | Kernel records the underlying IO |
| ⑤ Sub-agent dispatch | — | A2A broker adjudicates; verifies Signed Agent Card + transport identity | Chain narrowed, then issued by S3 | — |
| ⑥ Approval | Approval interaction and record; signs the action digest | Blocks and waits; checks digest equality at execution | Suspended | — |
| ⑦ Terminate | Result returned | — | Trajectory sealed | Daemon signs → uploads |
| ⑧ After the fact | — | — | — | S7 assembles and corroborates → S8 scores and feeds red-team findings back |
Key Constraint
The first hop can only be produced at S1. The Gateway and the runtime can verify and narrow it — they cannot create one out of nothing.
Blueprint ID: GOV-COMP-SEQUENCE-V1Sheet 08 / 12
Section 08 — Indivisible Bindings
Four things that must not be split
Split these and the architecture stops working. They are listed here so that "product independence" never breaks them:
| # | Must stay together | What breaks if you split it |
|---|---|---|
| 1 | Trajectory assembly & cross-corroboration (both in S7) | Reconciliation needs all three channels assembled in one place; apart, there is nothing to compare and corroboration exists in name only |
| 2 | Identity issuance & chain verification (both in S3) | Nobody guarantees monotonic narrowing; the chain can be forged or widened |
| 3 | PDP adjudication & decision_reason (both in S5) | You are left with "blocked" and no "why"; the most important post-incident question is unanswerable |
| 4 | The three collection layers (S6's three + S4's boundary channel) | They may be rolled out in phases, but the level must then be stated as L1 — it may not be called "provable" |
Blueprint ID: GOV-COMP-BINDING-V1Sheet 09 / 12
Section 09 — Module Alignment
Alignment with mainstream offerings
For readers already fluent in the AWS or Volcano Engine ecosystems. What is the same is stated as the same; what differs is explained.
| Capability | AWS Bedrock AgentCore | Volcano AgentKit Trust Plane | This architecture |
|---|---|---|---|
| Agent identity directory | Agent Identity Directory | Workload Pool + Agent Registry | S2 Registry and S3 Identity are separate: the directory is a policy hot-path data source, identity is the issuer — their consistency and latency requirements differ |
| Identity propagation | OAuth 2.0 Token Exchange | TIP Token (RFC 8693) | S3 uses the same mechanism (a pattern already proven at very large scale), plus jti · nonce · confirmation key · chain-length limit · revocation |
| Policy engine | Agent Authorizer | Cedar (RBAC / ABAC / ReBAC + IBAC) | S5: the adjudication input is "trajectory + current step", not a single call; the language is a two-layer combination of a decidable core plus pre-computed features |
| Credential custody | Resource Token Vault + Secrets Manager | Pass Vault | S3 vault + injection at the S4 Gateway (same idea) |
| Enforcement point | Managed runtime | Trust Plane Gateway (the only PEP) | The S4 Gateway is non-bypassable, but it is not assumed to be the only observation point — the S6 Probe adds a factual channel and an in-process semantic channel |
| Audit & observability | CloudTrail + CloudWatch | OTEL end-to-end trace + dashboard | S7 separates the audit projection from the observability projection (different sampling, retention and tamper-resistance requirements) + three-channel cross-corroboration |
| Evaluation | AgentCore Evaluations | (no public module) | S8 plus the three evaluator-isolation requirements |
| Endpoint collection | — | — (gateway-centric) | S6 Probe: eBPF / ETW / EndpointSecurity |
Four Design Positions
The differences above reduce to four positions: ① the trajectory is a first-class governance object (not an observability by-product); ② policy takes "trajectory + current step" as input (not a single call); ③ multiple enforcement points cross-corroborate (no one-sided trust in the SDK or the network); ④ the capability declaration is the single admission prerequisite (anything outside it is a violation). These map onto the three root requirements — attributable, constrainable, provable. Give up any one of them and the corresponding root requirement no longer holds.
Blueprint ID: GOV-COMP-ALIGN-V1Sheet 10 / 12
Section 10 — Onboarding
Onboarding: levels and the four-step path
10.1 Admission levels L0–L3
Onboarding cost and assurance strength are priced against each other. Levels must be monotonic (a higher level includes everything below it), recorded explicitly in the Registry and used as a policy input, and downgrades must be detectable — an agent that was L3 and stops sending signed events is itself an alert.
| Level | Name | What the onboarding side provides | Systems required | What the platform provides |
|---|---|---|---|---|
| L0 | Visible | Existence signals (process, network signature, DNS, directory registration) | S6 + S2 | Discovery, cataloguing, risk scoring, shadow-agent alerts |
| L1 | Attributable | Complete trajectory + delegation chain | + S1 + S3 + S7 | L0 + audit events, decision paths, retrospective tracing |
| L2 | Constrainable | Synchronously asks the PDP before acting and obeys the decision | + S4 + S5 | L1 + runtime interception, dry-run, kill-switch |
| L3 | Provable | Signed audit events + tamper-evident delivery + cross-corroboration anchors | All 8 | L2 + compliance-grade evidence, regulatory proof, accountability |
Assurance Discipline
Assurance level is not raised by counting installed components. The same agent may reach high assurance on network actions while local stdio, in-process memory and encrypted payloads remain low. Levels must be declared per action class × enforcement-point combination — with a separate reachable assurance stated for each of the seven classes: network / MCP / stdio / file / exec / memory / sub-agent. Labelling a whole agent with one level distorts both the security policy and the compliance statement.
10.2 The four-step path
| Step | Action | Work on the onboarding side | Provided by the platform |
|---|---|---|---|
| 1 · See it | Install probes, sync assets | Install the daemon on hosts; sync the existing agent inventory into the Registry | S6 probe packages (eBPF / ETW / ES) · S2 onboarding API |
| 2 · Identity | Onboard identity and delegation | Agents get a SPIFFE ID at registration; the Portal binds real human identity | S3 issuance paths (K8s UDS / bare process / microVM vsock) · S1 SSO federation |
| 3 · Funnel | Force routing through the gateway | Point tool / MCP targets at the gateway; strip plaintext credentials from code and environment variables | S4 gateway routes · S3 credential vault and provider templates |
| 4 · Prove it | Onboard policy and audit | Declare policy per resource / action; connect the existing SIEM | S5 policy templates and dry_run · S7 evidence packages and OTLP export |
Downstream Compatibility
No changes are required to authorisation code in GitLab, Argo CD, Kubernetes, SaaS and similar systems — credential translation happens at the gateway, and downstream keeps its native controls (branch protection, sync windows, IAM, RBAC, app authorisation scopes).
"Low-change onboarding" is not "zero integration work": gateway routes, resource mappings, credential profiles, policy baselines and network boundaries still have to be configured.
"Low-change onboarding" is not "zero integration work": gateway routes, resource mappings, credential profiles, policy baselines and network boundaries still have to be configured.
Blueprint ID: GOV-COMP-ONBOARD-V1Sheet 11 / 12
Section 11 — Delivery Bundles
Delivery bundles
You do not have to adopt all of it at once. Four bundles each stand on their own:
| Bundle | Systems | What it solves | Level reached | When it is not enough |
|---|---|---|---|---|
| See it first | S2 + S6 | How many agents exist, what they are doing, which MCP servers they touch | L0–L1 | You can see it but cannot stop it |
| Control it first | S1 + S4 + S5 | Funnel the entry point, control egress, block and stop | L2 | You can block, but the evidence is incomplete (no cross-corroboration) |
| Prove it first | S6 + S7 | Compliance evidence, regulator questions, incident accountability | L1–L3 | You have evidence but no enforcement point |
| Full stack | All 8 | The complete governance loop | L3 | — |
Lowest Entry Barrier
"Prove it first" is the lowest-friction way into an existing estate: deploy only the Probe and Audit, and feed the data into the SIEM you already run.
Blueprint ID: GOV-COMP-BUNDLE-V1Sheet 12 / 12