What an AI agent needs before it can act

The standard answer to agent safety is a permissions answer. Authenticate the agent, scope its credentials narrowly, log every call, put a human in the loop for anything expensive. All of that is necessary. None of it is sufficient, and the gap between the two is where the real failures live.

Deloitte surveyed 3,235 respondents across 24 countries for its 2026 State of AI in the Enterprise. The distance between those two numbers is not a governance backlog. It is a category of risk that most organizations have not described yet.

Why is write access different from read access?

A wrong answer is a bad sentence. A person reads it, disagrees, and moves on. The cost is a moment of doubt.

A wrong action is a purchase order raised against the wrong project. An approval routed to somebody who left the company in March. A document filed against a job that closed last quarter, where it will be found in an audit two years from now by somebody who has no idea how it got there.

This is the moment the whole problem changes shape, and it is why so little enterprise AI reaches the systems that run the business. Retrieval is safe because it is inert. The instant a system can change the state of the company, the question stops being "is this answer good" and becomes "does this system know what it is touching". Most do not, which is one reason so few pilots reach production.

What does an agent need to know before it can act?

Seven preconditions. None of them are model capabilities, and none of them are supplied by a credential.

1. 01Actor identity. Who the agent is acting as, and under whose authority. Not which service account it holds, but which human role it is standing in for and what that role is permitted to decide.
2. 02Object identity. Which specific real thing the action touches, resolved the same way across every system that holds a version of it. If the ERP, the document system and the project tool each hold a different identifier for the same job, the agent is acting on a guess.
3. 03Relation. Which relation the action changes. Adding a cost, assigning an owner, attaching a document and naming a counterparty are four different operations, and they carry four different consequences.
4. 04Lifecycle state. Where the object currently sits in its lifecycle, and whether the transition being attempted is legal from that state. Most wrong actions are legal operations performed on an object in the wrong state.
5. 05Authority boundary. Whether this action crosses a line that requires a person. Committing money, binding a counterparty and closing a record are boundaries; recalculating a forecast is not.
6. 06Reversal. What undoing this action consists of, decided before the action is taken. An action whose reversal was never designed is not reversible because somebody says it is.
7. 07Receipt. What record the action leaves, in terms the business already uses. Not a log line recording that an API was called, but a statement of what changed in the organization's record of itself.

Why permissions are not enough

Take an agent authorised to post costs. It posts a real cost, to a real cost code, on a project that closed last quarter. The credential was valid. The scope was correct. The API accepted the call. The audit log records a successful write by an authorised actor.

Nothing in the credential model knew the job had a lifecycle, that the lifecycle had a terminal state, or that posting into a closed project is the kind of mistake that surfaces at year end. Permissions are a statement about who. Safety here is a statement about what, and the two are answered by different systems.

What is an operational data model, and how is it different from an ontology, a knowledge graph, or a semantic layer?

These four words are used interchangeably in vendor material and they do not mean the same thing. The distinction that matters for agents is what each one decides, and what each one leaves undecided.

A knowledge graph will tell an agent that a document is related to a project. It will not tell it that the project is closed, that closure is terminal, and that attaching anything to it now requires a named person to reopen it. That is a different kind of fact, and it is the kind that governs writes. It is what the model is built to hold.

Is any of this a new argument?

No, and it is worth being direct about that. Palantir's Foundry Ontology has named this layer for years. Its documentation describes a semantic layer of objects, properties and links, a kinetic layer of action types and functions, and a dynamic layer for security. The kinetic layer is the write action, formalised, with staging, review and audit built around it.

Anyone claiming to have discovered that the write action matters is either unaware of that work or hoping you are. The interesting disagreement is not whether an operational model is needed. It is how one gets built.

A bespoke ontology is an engagement with no natural completion criterion. Every class, every relation and every state has to be discovered, argued over and agreed. That is why this capability has historically belonged to organizations that could fund a multi year programme to obtain it.

The alternative is to treat the structure as something recognised rather than authored. Operational businesses repeat, so the shape a company runs on is usually a shape somebody has built before. What differs is which object sits in the middle, and that is a question with a short answer in any given company. We describe how that works on the model, and the object changes by sector.

Why can't our ERP vendor's agent do this?

It can, inside its own data. That is the constraint, and it is structural rather than a criticism of anyone's engineering.

Real operational work spans four or five systems. The commercial terms live in the ERP, the drawings and the signed variations live in the document system, the schedule lives in the project tool, and the decision that actually changed the job lives in somebody's inbox. Those systems hold different versions of the same object, and no one of them is positioned to say which version is the record.

An agent confined to one of them will act correctly within its own view and still be wrong about the business, because the view is partial by construction. No incumbent has a commercial reason to tell you the problem sits above their product.

Informatica sells data management software, so this is vendor commissioned research and should be read with that in mind. It is reported here because the sample and date are stated and because it measures the barrier directly rather than predicting one.

What does a good receipt look like?

A log line records that a call was made. A receipt records what changed in the organization's account of itself, in words the business already uses. The difference matters at the moment somebody asks why a number moved.

• What was proposed, in one sentence a person who was not there can understand.
• Who the agent was acting as, and under whose authority.
• Which object and which relation the action touched.
• What changed, and what the value was before it changed.
• What the reversal is, and whether it is still available.
• Who confirmed it, if confirmation was required, and when.

When should a human still confirm?

The useful threshold is consequence and reversibility, not confidence. An action that is bounded and reversible can proceed and be reviewed after the fact. An action that is irreversible, that commits money, or that crosses a boundary to a counterparty should wait for a person, however sure the system is.

Gartner predicts that over 40 percent of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. That is a forecast rather than an observed rate, and it was published on 25 June 2025. Read it as a description of where the risk is concentrated rather than as a measurement of failure.

The organizations that will not be in that number are the ones that answered the semantics question before they answered the permissions question. What that looks like in a rollout is the subject of a separate piece.