Your AI agents have logins. Most of them have no owner.

Finding every agent running in the business turned out to be the easy part. The harder question is what each one is permitted to touch, and whether anybody decided that on purpose.

What happened

The Hacker News published a piece arguing that seeing AI agents is not enough. Most of the last year's security tooling went into answering one question: which agents are running in here. That question is now more or less answered, and it was the easy one.

The harder problem is that an agent does not behave like an application. An application walks a fixed path, so you grant it access to what that path needs and the grant stays accurate for years. An agent works toward a goal and picks its own route. Give it a credential on Monday for one job and by Friday it is using the same credential for something nobody scoped.

Sitting under that is an identity problem. Most agents running in businesses today authenticate as a person, usually whoever set them up. The audit log names an employee. The thing taking the action is software.

Why this matters to your business

Two things break when an agent runs on a borrowed login.

The first is your record of what happened. Something goes wrong, you pull the logs, and you get the name of somebody who was at lunch. Access reviews degrade the same way. Every quarter a manager signs off attesting that each account's access is appropriate, and more of what they are signing for is software they have never seen.

The second is blast radius. An agent built to look up order status is often handed the login of a support lead, because that was the account nearest to hand. That login can also issue refunds, merge accounts, change the email address on file, and export a customer list. Nobody asked the agent to do any of that. It is simply able to. The distance between what an agent was built for and what its credential permits is where the incident happens.

Why this is a CX-Builder use case

The answer here is not another scanner. It is building the agent so its permissions are part of what it is, rather than something it borrowed on the way in.

CX-Builder runs on infrastructure you control, and that changes what is available to you. Each agent is a flow you can look at and read: which tools it can call and which actions stop for a person. Because the flow is the definition of the agent, the boundary is not a policy document filed next to the system. It is the system.

In practice that means retrieval scoped to one document set instead of a general search over everything. A tool list with four entries instead of a credential that opens the whole platform. A human-in-the-loop gate in front of anything that moves money or leaves the building. And because you host it, the credentials the agent uses are ones you issued, hold, and can revoke this afternoon without filing a ticket with a vendor.

What this looks like if you build it

Give each agent a service account of its own rather than a person's, then scope that account to what the flow actually calls. The flow gets only the connectors the job needs, so the credential and the capability stay the same size. Anything with financial or contractual weight goes behind an approval node, which holds the proposed action for one-click review instead of executing it. Runs are logged per flow, so the record names the agent and shows what it saw.

The payoff is ordinary and worth having. Revoke one credential and one agent stops. Everything else keeps working, and you know exactly what you turned off.