Your AI agent's access should expire when the job does

Machine identities already outnumber people by more than a hundred to one. Standing access is what turns that count into an exposure, and it is the part you can fix this quarter.

What happened

CDO Magazine published a practical guide to managing agentic AI security, risk and control. The argument is narrow and correct. Governance written for models covers accuracy, bias and disclosure. Software that calls APIs and takes actions on its own needs a different set of controls, and most businesses have not written them.

The mechanics are worth stating plainly. An agent that completes a multi-step task authenticates several times along the way. So do its sub-agents, and so does every tool process it starts. Each of those is an identity that some system has to recognise. Palo Alto Networks puts machine identities at 109 for every human one, driven largely by this pattern.

Three older controls break under that load. Static permissions cannot anticipate what an agent will need to reach, so they get widened until they cover everything. Human review cannot read decisions that arrive at machine speed. And when several agents share one service account, nothing in the log tells you which of them acted.

Why this matters to your business

The exposure is standing access. Permissions granted to an agent on its first day are still live on day four hundred, long after the job that justified them changed shape. A credential that never expires is a credential someone else has time to find.

The shared-account version costs you more than that. If four agents authenticate as the same account and one of them does something wrong, you cannot tell which. The only safe response is switching off all four while you work it out. That is an outage you agreed to in advance, at the moment you decided one login was simpler.

Four signs the gap is already open in your own setup:

• Two or more agents authenticate as the same account.
• An agent holds broad access it uses for one narrow task.
• You can reconstruct what an agent did, but only after the fact.
• Your risk team reviews an agent before launch and never again.

Why this is a CX-Builder use case

The controls the article asks for are ordinary once you stop treating an agent as a single program. Give every agent, sub-agent and tool process its own identity. Scope its credential to the systems that one job touches, and give it an end date. Authorise the actions that move money or create legal obligation one at a time. Put those limits outside the model, where a prompt cannot reach them, and keep a record with a name attached to every action.

CX-Builder runs on your own infrastructure, which is what makes the first part cheap. Credentials live in your store, not a vendor's, so one flow can hold a connection scoped to one system while another flow holds a different one. There is no house account that everything shares because there is no reason to create one.

The per-action part is a human-in-the-loop gate. A refund above a threshold, a contract change, a record deletion: each stops and waits for a person who sees the proposed action and approves that action, not the agent in general. Everything under the threshold runs and is logged. The log stays on your host, which is what lets you answer the attribution question in the middle of an incident instead of a week later.

What this looks like if you build it

One flow per job, and one credential per flow, scoped to the systems that job actually reads and writes. An approval node sits ahead of every write that costs money or changes a commitment, so the flow pauses there rather than reporting afterwards. Iteration limits cap the retry loops that let a small mistake reach a hundred API calls. Runs are logged against the flow that produced them, which gives you the name you need when you ask who did this.

Rotation is the part teams skip, and self-hosting is what makes it survivable. When a credential is defined once and referenced by one flow, replacing it is a single edit rather than a hunt through every integration that borrowed it.

The article suggests spreading this over twelve months, and the first ninety days are the ones that matter. Inventory the agents you already run, give each one an owner by name, and delete the shared credentials. Scoping and per-action approval get much easier once you know what exists.