Cloud and platform operations, with an agent holding the keys

If you are not the platform team, here are the two sentences to carry into a meeting: the agent gets no keys of its own, and everything it wants to do goes through a checkpoint that holds them all. Only the irreversible steps wait for a person, and the routine fixes stay automatic.

The scenario

A platform team runs an internal deployment tool: it takes a container image, migrates the database, shifts traffic, and writes a change record. The team also has cloud accounts, a secrets store — the vault where passwords and access keys are kept — and a shell host for the awkward jobs.

An agent is pointed at this. It reads alerts, works out what broke, and fixes it — roll back a bad release, restart a stuck worker, scale up under load. This is the most natural place to put an agent, because the work is well-documented and the on-call rota is expensive. It is also the hardest place to control.

How it goes wrong

The agent does not have to use your tools. An agent that can run code and holds credentials is not restricted to the paths you designed for it. Faced with a deployment tool that refuses something, the natural next move — for a model that is trying to be helpful, not a malicious one — is to call the cloud provider's API directly, with the same credentials and nothing in the way.

So a checkpoint in front of the deployment tool sees a tidy stream of allowed requests while consequential things happen elsewhere: databases deleted, standing admin permissions granted (access that never expires), provider keys read out of the secrets store. Your own records show one deployment; the provider's records show the rest.

The cloud provider's own safeguards do not close the gap either. Cloud platforms offer a protection flag that stops a resource being deleted, and it works: the delete is refused. But the same identity can clear that flag with an ordinary configuration change — no approval and, unless someone has set up an alert, no notification — and then delete the resource for good.

Where the checkpoint goes

Not in front of your own tools, but in front of everything the agent can reach, including the cloud provider's API and the secrets store. The agent runs with no credentials of its own and no network route except the checkpoint; the checkpoint holds the credentials and uses them on the agent's behalf, one checked request at a time.

This does mean putting a checkpoint in front of systems that are not yours — the provider's API, the secrets store. What makes that practical is that the list of actions worth routing this way is short.

The rules that matter

None of them is a rule about deployments. In plain terms: nothing is deleted unless it is known to be unused; switching off a resource's delete-protection waits for the platform lead; the agent may never read a permanent provider key; and any new access permission must come with an expiry date.

Resource.delete:
  precondition: [theResourceIsKnownToBeUnused]

Resource.clearDeletionProtection:      # the enabling change
  requireApproval: { approvers: role:platform-lead }

Secret.read:
  denylist: { set: static-provider-keys }   # a key with no expiry

AccessGrant.create:
  requireApproval: { when: "data.expiry == null",
                     approvers: role:platform-lead }

The second rule matters most, and it is the same shape as the bank-detail rule in the payments case: the approval sits on the enabling change, not on the damage it unlocks. We measured the alternative of putting the approval on deletion directly: gating only the enabling change gave the same protection and refused one fewer legitimate operation.

The third rule is about credentials that never expire. A permanent key the agent reads once is a copy of your production access that no later control can take back. If your secrets store can issue short-lived credentials, use that; if it cannot, the read is at least now something the checkpoint can refuse and record.

What you get

• "Can the agent reach anything we are not checking?" becomes answerable. You answer it by looking at the network setup and one mapping table. The checkpoint verifies the half it can see — it refuses to start if its own configuration routes a tool around it — while making the network offer no other path is work in your systems, which it cannot check from inside.
• Only the irreversible steps wait for a person. Deleting data, clearing a protection flag, granting standing access. Restarts, scaling and rollbacks stay automatic, which is what makes the agent worth having.
• The record answers a question cloud logs cannot. Cloud audit logs show what reached the provider. This record shows every request the agent made, allowed or refused, and who it was acting for.
• The provider's guard rail becomes a real control. The protection flag stops being something the agent can quietly switch off.

What it will not do

• A checkpoint the agent can skip is not a control. The version that lives inside the agent's own software only checks an agent that chooses to use it. In our testing, an agent bypassed that version in under a second by using the credentials it already held. Use that shape for convenience; do not rely on it for control.
• It cannot tell a good change from a bad one. A correctly-formed rollback to a broken release is within the rules, and it will run.
• Its reach depends on your own housekeeping. The delete-protection rule only covers resources that have the flag switched on. Whatever share of your systems has it off is the share this does not protect.