Deployment pattern
Cloud Control Plane Governance
A deployment pattern, not a shipped integration. Retain signed policy decisions for covered cloud-management calls routed through aga-proxy. A reviewer can check those records offline, alongside provider logs and change approvals. Coverage gaps and deployment controls still matter.
Cloud Infrastructure
01
Target System
Agents that operate cloud control planes or infrastructure-as-code on a team's behalf, where a customer's reviewer asks which changes the agent was allowed to make.
02
What the gateway would sign
- Recorded change decisions
- When an agent requests control-plane changes through tool calls routed to aga-proxy, each recorded decision is signed PERMITTED or DENIED with the SHA-256 of the policy's canonical JSON. Known issues 6 and 7 on /security describe coverage gaps.
- Per-environment records
- One gateway per environment gives each environment its own signed, hash-linked chain under its own key.
- The export
- An evidence bundle your customer's reviewer checks offline against the published format and the key you gave them.
03
What you build: not shipped
- Routing
- Expose the control-plane operations as MCP tools behind aga-proxy. The published packages include no cloud-provider or IaC integration.
- Drift detection
- AGA does not compare cloud configuration with a baseline. Drift detection stays in the tools you already run.
- Blocking
- In-path, aga-proxy does not forward a call it denies. Whether the agent has other credentials to the control plane is a property of your deployment.
- The policy
- aga-proxy's default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. The built-in profiles name example tools, so rules for your own tools need a custom --policy.
04
What the record proves, and does not
- The change decisions present in the exported record, as the verifier parses them: a field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security)
- Checkable offline, with no access to the provider's logs
- Not that every change went through the gateway
- Not the state of the infrastructure after a permitted change
Sample bundle
The same representative sample bundle offered site-wide: four Ed25519-signed receipts, Merkle proofs, a signed checkpoint, and an offline verifier. There is no cloud-specific variant.