The Three Questions to Ask Before an Agent Acts on Your ERP
Permission is not legitimacy — and your stack only checks one of them.
An agent changes a customer’s payment terms. Everything works exactly as designed.
The identity platform confirms the agent is authorized to act on that account. The audit log captures which agent made the change, and when. Every control fires correctly. Every dashboard stays green.
Nobody can answer the only question that matters: should those terms have changed, on that customer, at that point in the order lifecycle?
That question doesn’t live in the identity platform. It doesn’t live in the audit log. It lives in the credit policy, the customer’s payment history, the order’s current state, and a threshold that exists in somebody’s head and in a slide deck from 2023.
Permission is not legitimacy
We spent two decades building controls that answer one question. Was this permitted? Roles, authorizations, segregation of duties, approval hierarchies. That machinery is good, and it was built for a world where the thing taking the action was a person who already knew the business.
Agents need a second question nobody built for. Was this correct?
Those are different questions. They live in different systems, and no product on the market merges them — though several will tell you otherwise.
An agent can be fully authorized and still do the wrong thing. When it does, nothing in your stack raises its hand, because from the stack’s point of view nothing went wrong.
Question 1 — Who authorized it?
This part is genuinely being solved, and solved well. Worth saying plainly, because most writing on agent governance is unrelentingly grim and this half isn’t.
Agent identity is consolidating the way single sign-on consolidated. Agents get their own identities, scoped permissions, an owner of record, and a revocation path. The identity layer is estate-agnostic by nature — it doesn’t need to know what a delivery document is — so it federates cleanly across systems, and the vendors doing it are converging fast.
If your organization runs Microsoft 365, you already have the substrate for this whether anyone deliberated about it or not. If you’re heterogeneous enough to have brought in a dedicated identity provider, you likely have a stronger version.
Your CISO is already on this one. Let them run it.
Question 2 — Where can it actually be stopped?
Here the received wisdom is wrong.
Most buyers assume governability is a property of the agent — that you control the agents you bought from your vendor, and the foreign ones are the problem.
Microsoft documents the actual mechanism candidly in its own guidance: calls that don’t reach the identity platform can’t be evaluated by its access policies, carry no risk signal to calculate, and can’t tie an audit record to a specific user. An agent endpoint that doesn’t require authentication is a reachable, ungoverned surface — regardless of who built the agent behind it.
That runs both directions, and both directions matter. A third-party agent onboarded properly and routed through a governed path is controlled. Your own vendor’s agent, reaching a resource through a static API key, is not.
Governability follows the route, not the logo.
So when a vendor tells you they govern all your agents, they’re answering a narrower question than the one you asked. They govern what crosses their path. That’s real, and it’s worth having, and it isn’t the same as knowing your business.
For a real estate the consequence is this: one consequential action touches three or four systems, and the ones that can stop it are frequently not the one that can judge it. A workflow platform mediates the request and can block it — it owns the route. The identity platform can revoke the agent’s access — it owns the credential. But the transaction lands in your ERP, and only the ERP knows the order’s current state, the credit segment, the exception in play.
Question 3 — What determines it was valid?
Nobody has a clean answer for this one, and it’s where your exposure lives.
Validity isn’t a property of the agent, the credential, or the route. It’s a property of the situation: this customer, this order, this point in the lifecycle, this operating mode, this exception. Answering it takes the process state, the transactional rules, and specific knowledge of which deviations from the standard path are legitimate.
Some of that lives in your application. Some lives in a policy document. A great deal lives in the head of a process owner who has no console, no admin rights, and no ability to stop anything.
The person who knows whether the action was legitimate is usually not the person who can prevent it.
Why grounding doesn’t answer question 3
The instinctive fix is to make the AI understand your business — ground it in your own documents, your history, your transactions. Reasonable instinct. It’s also where a specific kind of trouble starts.
Your transactional history records what happened. It doesn’t record what should have happened.
It doesn’t capture what alternatives were available and rejected, why an exception was approved, which rule was waived, or which outcomes were tolerated because it was quarter-end and the shipment had to move. A completed transaction proves something occurred. It proves nothing about whether it was correct.
Stacked on that is the long tail. A few paths carry most of the volume. Then there’s a tail of rare variants — some entirely legitimate, like the consignment arrangement that bills on consumption; some workarounds for problems nobody fixed; some the scar tissue of a master-data error that’s been quietly generating exceptions for two years.
In the transactional record, all three look identical. A legitimate-looking path with a document at the end.
Ground an agent on that and you don’t get a system that understands your business. You get one fluent in your history, including the parts you’d never have approved.
Your history is not your policy.
Grounding can teach an agent how your company has behaved. Something else has to tell it which of that behavior was right — the explicit, machine-readable statement of what must be true before an action commits. That layer is the one almost nobody has built.
The platform vendors have seen it coming. Both major process-intelligence players are building a governed layer designed to hold exactly this kind of business knowledge: rules, constraints, guardrails for agents. Some of it is shipping, some is in beta, some is on the roadmap for later this year. Read the documentation closely and you’ll notice something else. They’re building the container and asking you to fill it.
That’s the honest state of the market. The artifact is being standardized. The authoring is still yours.
The test: trace one action
Don’t start with a vendor evaluation. Start with one action.
Pick something consequential an agent could plausibly do. Change payment terms. Release a blocked order. Confirm a production order. Then trace it:
Who created or sponsors this agent? A named human, not a team.
On whose behalf does it act? Its own identity, or someone’s delegated authority?
What authorizes the action? Identity plus policy — and is there a path that bypasses both?
Where can it actually be stopped? Name the enforcement point. If you can’t, that’s the answer.
What determines the action was valid? A rule, a state check, a process model — or a person who would just know?
What records the reasoning and the result? And can you join those records afterward?
Who owns the exception when it goes wrong? By name.
The reason to run this now rather than later: it works before you deploy. It doesn’t require agent sprawl. Most organizations don’t have it yet — roughly one in six has an agent in production, while about two in five enterprise applications are expected to ship with one embedded by the end of this year.
The gap between those two numbers is the window you’re in.
The clock isn’t the vendor roadmap
If this reads like an architecture problem you can schedule for next year, one detail deserves your attention.
The control frameworks are moving. Internal control expectations are now being written to reach directly into AI system architecture — model lineage, deployment approvals, decision logs, dependency mappings treated as production-readiness artifacts rather than documentation assembled afterward. And the retention clocks are already running: six months for high-risk systems under the EU AI Act, and in US financial services a six-year default under FINRA’s books-and-records rule, with SEC periods running three to six years depending on the record class.
When the control framework moves, external audit follows. The requirement arrives on somebody else’s schedule, and it doesn’t wait for a vendor category to exist.
You may be asked to reconstruct an agent’s decision before anyone has sold you a way to do it.
What would change my mind
One claim here is load-bearing and unproven: that no platform currently validates an autonomous agent’s action against live transaction state, across multiple systems, before it commits.
Neutral platforms already do far more cross-system process work than most buyers realize — reconstructing business objects across different applications, detecting deviations from an intended process, triggering remediation. That’s real, and more mature than the skeptics allow.
What I couldn’t find in any public production case is the pre-commit version: an agent proposes an action, the action is judged against current state across systems, and it’s allowed, escalated, or blocked before anything is written.
If that exists in a named production customer, this analysis narrows considerably, and I’d want to know. Until then, treat “we govern your agents” and “we can tell you an action was wrong” as the same claim at your own risk.
Where to start
Not with a control tower.
Trace one action. Find out where it can be stopped, and what decides whether it should be. The gap between those two answers is the thing to fix first — and it will be more specific, more fixable, and considerably cheaper than whatever is currently in your evaluation pipeline.