The fifth meeting about the accounts-payable agent ran forty minutes and produced one action item, which was to schedule a sixth. Nine people attended. Two of them had attended all five.
The agent works. It reads an invoice, matches it against a purchase order, flags what does not reconcile, and pays the rest. It was built in six weeks by three people who now maintain other things. The demo has been given to the CFO twice, and she liked it both times.
What it does not have is approval to run against production, and the reason it does not is a sentence that has been said, in some form, in all five meetings: we cannot put live payment credentials inside a system whose behavior we cannot enumerate.
Everyone in the room hears that as an objection to the agent. It is not. It is an objection to a specific piece of engineering, and it is correct.
The reviewer is not being difficult
Enterprises have a working method for approving software that holds a credential. You establish what the software does, you bound it, you review the bounds, and you accept the residual risk on the basis that the behavior is knowable. It is not a bureaucratic ritual. It is the entire basis on which anything gets signed.
An agent breaks the first step. Not because it is dangerous, and not because the model is unpredictable in the sense people mean when they say that word, but because the set of actions it might take is not enumerable in advance. That is the property that makes it useful. It is also the property that makes the existing approval method return nothing.
So the reviewer does the only defensible thing available and refuses to certify what cannot be characterized. Then the team returns with a longer document, and the reviewer refuses it again, because length was never the deficiency. Five meetings is not dysfunction. It is two competent parties applying an approval method to a case it does not cover, and neither of them is empowered to say so.
What the room is actually arguing about
Listen to the objection again and notice that it contains two claims fused into one. The first is that the agent's behavior is not enumerable. The second is that the agent will hold a live credential. The first is a fact about agents and will not change. The second is a decision somebody made in the second week of the build, without discussion, because that is how every other integration in the estate works.
Fuse them and you get an impasse, because you are asking the reviewer to accept unbounded behavior with live access attached. Separate them and the impasse becomes a design question with an answer.
The answer is that the credential does not have to be there. The application, and the agent acting through it, can carry a stand-in that is accepted nowhere. At the moment a call leaves the boundary, the real value is substituted: read from the enterprise vault for that one call, or released from the phone of the person who owns it. What returns is the result. The agent gets its outcome. It never gets the value, and neither does anything the agent can influence.
This is not a mitigation. Mitigations are what you offer when the reviewer's concern stands and you are proposing to manage it. Here the concern's subject is removed. The question "what happens to the credential when the agent misbehaves" has no referent, in the way that a question about the contents of an empty box has no referent.
And then you do it eleven more times
Suppose the AP agent clears. Behind it are claims, servicing, procurement, the reconciliation tool somebody built in Sheets, and the vendor product nobody can modify at all. Every one of them will arrive at the same meeting with the same sentence, and a CIO looking at that queue is right to be unenthusiastic about the precedent.
Because if the remedy is engineering, you have not solved the problem. You have priced it. A change request per application, a design decision about where this one keeps its secret, a test cycle, a release, and a fresh review to confirm that the thing you did in service four resembles the thing you did in service one. Twelve applications is twelve of everything, and the twelfth is not cheaper than the first: it is more expensive, because by then the estate has twelve slightly different answers and somebody has to hold them all in their head. This is the shape of every security program that quietly stops at four.
What makes the substitution worth arguing for is precisely that it is not that. It happens where the call leaves the boundary, not inside the application, and the application is not modified: it keeps its stand-in, calls the same destination, and is never told anything happened. So the remedy is not a code change repeated twelve times. It is a policy at a place all twelve already traverse. The first one takes an afternoon of thought. The twelfth is a line of configuration, and it works on the vendor product too, which is the case that has no engineering answer at all.
The reviewer's decision generalizes for the same reason. They are not certifying an application; they are certifying a shape. Approve it once and the next eleven arrive already inside it, which is the only version of this that ends with a program rather than a pilot.
The objection that survives this
Here is the version of the concern that removing the credential does not touch, and it is the stronger one.
An agent that can cause a payment to happen is consequential whether or not it holds the means to make one. If the substitution is transparent, if the agent asks for a payment and a payment occurs, then from the perspective of the money, very little has changed. You have moved the credential out of reach and left the capability in place. A reviewer who says so is not missing the point; they have found the real one.
That objection has an answer too, but it is a different answer, and conflating the two is how these conversations get muddled. Removing the credential changes what a compromise yields: a leaked stand-in buys an attacker nothing, and an agent that has been talked into something cannot exfiltrate a value it never held. What it does not do is bound the action. Bounding the action is a separate control: which calls are permitted, under what conditions, and which ones stop and wait for a named person to agree. That is the conversation the room should be having in meeting six, and it is one the enterprise already knows how to hold, because deciding which actions are allowed is ordinary work.
The point is not that the credential question is the only question. It is that it is the one blocking the others from being asked.
Why this keeps happening
Because the credential-in-the-application pattern is thirty years old and invisible. Nobody in the AP project chose it. It arrived with the first HTTP client anyone wrote, it is how the estate works, and it was never a decision anyone would have thought to record. That is exactly why it survives five meetings of scrutiny: the room examines the agent minutely and never examines the assumption underneath it, because assumptions of that age do not present themselves as choices.
It also explains why the meetings feel unfair to both sides. The team believes it is being asked to prove a negative, which it is. The reviewer believes it is being asked to lower a standard, which it also is. Neither can concede without being wrong, and so the calendar entry recurs.
Meeting six
The useful thing to bring is not a longer risk document. It is the same agent with the credential removed, and one sentence: the agent no longer holds anything that works, so tell us which actions it may take.
That is a question a reviewer can answer in the room. It is also, unlike the last five, a question that has to be answered only once, because the next agent will arrive with the same shape, and the shape is now approved. The organizations that will run agents at scale are not the ones with better models. They are the ones that stopped asking their reviewers to certify the uncertifiable, and gave them something they were equipped to judge instead.