Headless ERP Removes the Screen. Some of Your Controls Only Existed There.

Enterprise software is being rebuilt so that AI agents can do the work without ever opening a screen, and a surprising number of the rules in a typical ERP estate were built on the screen. When the agent goes in through the API, those rules do not fail. They simply are not there, and nothing in the transaction says so.

Headless is the right architecture for agents, and I would not slow it down. The point is narrower: before you open the side door, find out which of your controls were only ever guarding the front one.

What Salesforce actually announced

In April, at its TDX developer conference, Salesforce launched Headless 360 with a simple promise: everything on its platform is now an API, an MCP tool or a CLI command that an agent can call. It said more than 60 new MCP tools were available at launch. On 4 September its release notes recorded that Headless 360 had been rebranded AIforce, and at Dreamforce Khushwant Singh, who runs product management for the platform, put the idea plainly: Salesforce had opened up "all of its trusted capabilities to any AI, any interface, any agent, without requiring a Salesforce UI."

Five days before Dreamforce opened, the company introduced what it calls the Trusted Enterprise AI Harness, part of which it describes as "combining flexible AI reasoning with deterministic controls where certainty is required."

Salesforce is not alone. SAP has been moving the same way, through Joule and its Agent Gateway rather than raw APIs, and I argued in an earlier post that its API policy was the first honest architecture spec for agents on ERP. Microsoft's Copilot redesign last week previewed Autopilot, a persistent agent with its own identity that keeps working while you are doing something else. Every major vendor is converging on the same picture: the interface becomes optional, and the business logic becomes something an agent calls.

Deterministic controls where certainty is required is the right instinct. The question it leaves open is where your deterministic controls actually live today.

Where your controls actually live

Ask a finance systems team to walk you through how a business rule works, and listen for the word "screen." You will hear it more often than you expect.

Twenty years of implementation work got done this way. The screen was the door most people used, so the screen is where a lot of rules were put. A few examples, all documented behaviour rather than bugs:

Salesforce. A field can be made required in two very different ways. Required at the field level, or through a validation rule, and the platform enforces it on every create or update, whichever door the save comes through. Required on a page layout, and it is enforced only for someone typing into that layout. An integration or an API call saves the record without it. Plenty of orgs have "you cannot save an opportunity without a close reason" implemented the second way, because it was quicker.

NetSuite. Client scripts, by Oracle's own description, are executed "in the client browser." They are a common place to put field checks, defaulting logic and warnings on transaction forms. A web services call or a server script never loads the form, so those checks never run. User event scripts do run for web services and CSV import, unless someone has cleared the "Run Server SuiteScript and Trigger Workflows" option for that channel, which is exactly why it matters which kind your implementer chose.

Microsoft Dataverse (Dynamics 365 Sales and the other apps built on it). Business rules have a scope. Set it to the entity, and the rule runs on the server for every create and update, whatever the source. Set it to a form, or to all forms, and it runs in the browser only while someone is on that form.

SAP. Authorization checks in SAP mostly sit in the application logic, which is a genuine strength. Segregation of duties is where it gets subtle. A BAPI or OData call is never started through a transaction code, so the transaction code check never happens on the way in; the system checks the RFC or service authorization instead, then whatever the application code checks. SAP Access Control has supported Fiori apps and OData services in rulesets for years, but many rulesets still describe each function by its transaction codes, and many customers run analysis at that level only because it is quieter. A ruleset keyed only on transaction codes will report a clean user who can do the conflicting work through a service.

None of these vendors is hiding anything. The server-side option exists in every case, and it is documented. The screen-level option was chosen, usually years ago, because it was faster to build, easier to change, or because the person building it was thinking about users, not agents.

Why this did not bite before

Integrations have always bypassed the screen. So why is this a new problem?

Because integrations were enumerated. A large SAP estate runs hundreds of IDoc and RFC flows, but each one had a spec, an owner and a service account, touched known objects, and was tested by people who knew which fields it wrote. If it skipped a screen-level check, someone usually noticed and added the check to the mapping. Controllers who have cleaned up after a bad Data Loader or Winshuttle run know the other shape of this, and the fix then was restricting who could run the tool.

You cannot restrict an agent that way. There will be many of them. They act on behalf of a user, often with that user's permissions. They decide at runtime which object to touch and what to write, based on a request nobody reviewed in advance. And they are fast. An agent that can create a vendor, change bank details and release a payment in the time it takes a human to open the first screen is an old risk with the one thing that used to contain it removed.

Running the agent under a scoped service principal, which I have argued for before, does not close this. The principal decides which objects the agent may write. It says nothing about which checks run on the write.

The part I find most uncomfortable is that nothing looks wrong. The record saves. The API returns success. The record carries no flag that a check was skipped. The channel usually is logged, in NetSuite's system notes, Salesforce's event monitoring, SAP's gateway log, and almost nobody reads it next to the control.

What your SOX testing does and does not tell you

Your key application controls are probably in better shape than this makes them sound. Posting period locks, tolerance limits, release strategies and dual control on vendor bank changes are usually configuration, and configuration applies whichever door the request came through.

So pull last year's test steps and read them with one question. If the tester inspected a configuration setting, the control holds for any channel. If the tester tried the violating action and watched the system refuse, ask which door they used. It was the screen.

Your auditor also tests interfaces, but only the ones on the inventory, and for whether the data arrived complete, not whether the screen's rules applied to it. An agent is not on the inventory.

And the rules that never made it into SOX scope, the credit limit on the form, the discount ceiling in a page layout, were never tested by anyone. Those are the ones I would worry about first.

The Screen Test

Here is the exercise I would run before any agent gets write access through an API. It takes a small team a few days.

Step one: list the rules that matter. Start with the key application controls from your SOX scope, then add the operational rules your business would be embarrassed to break: credit limits, discount ceilings, three-way match, vendor bank change approvals, posting period locks. Twenty to forty items is typical. Do not try to inventory everything.

Step two: for each one, write down where it is enforced. There are really only three answers.

Step three: mark everything not enforced at the service layer. Those are the rules an agent can walk past. For each, pick one of three responses, and write down which.

  1. Move it down. Rebuild it as a server-side rule. This is almost always the right answer and often a small piece of work, because the platform already supports it.
  2. Gate the agent path. If the rule cannot move, put an explicit check in front of the agent's action: an approval step, a threshold, a policy in the vendor's control layer, or a wrapper function that checks preconditions before it calls the API, which is what SAP's endorsed pathways are for. This is what "deterministic controls where certainty is required" should mean in practice.
  3. Accept it, in writing. Some screen-only checks are conveniences, not controls. Fine. Say so, and have the owner sign it.

Step four: re-test from the API. Take the four or five highest-risk rules and have someone attempt the violating action through the same interface the agent will use. If it saves, you have your answer, and a far better conversation with your auditor.

For agents your vendor ships inside the product, you cannot run step four yourself. Ask the vendor, in writing, which of your server-side rules its agent actions honour, and whether any of them go around your customisations.

A note on segregation of duties, since it will surprise people most. If your analysis stops at transaction codes, the Screen Test will not fix it; the ruleset needs to describe conflicts in terms of the authorizations and services an agent actually calls. That is a larger piece of work, and it is worth starting before year-end testing rather than during it.

If your estate is already clean

A well-run ERP estate already enforces most of what matters on the server. SAP's authorization checks sit in the business logic. Salesforce validation rules run on every create and update, whatever the channel. Your implementer may have been disciplined from the start, in which case the Screen Test takes an afternoon and finds very little.

I hope that is your result. My experience is that the core platforms are sound and the exposure sits in the layer your company owns: the customisations, the quick fixes, the rule someone added to a form in 2017 because a region kept getting a field wrong. That layer is exactly where agents will spend their time, because it is where your business actually differs from the vendor's defaults.

I argued in July that the harness is where your exposure sits. It is also where the enforcement sits, which is why what it has been told to enforce is the whole question. A harness can only hold the rules it has been given. If nobody has written down that the discount ceiling lived in a page layout, the harness will not know to hold it.

Where this lands

Headless is coming whether or not you plan for it, and it should. Agents that can work through the business logic directly are a large part of what will finally make ERP AI pay for itself.

The screen was never meant to be a control. It became one by accident, because for twenty years it was the main way in. The move to agents is a good moment to put the rules where they always should have been: in the system, not in front of it.

Find out which of yours were only on the screen. Then move them down before anyone walks around them.

Shubhendu Tripathi is an AI and ERP strategy consultant based in Toronto, and the host of The Integration Layer, a podcast on AI, enterprise systems, and the work of making them fit together. Connect on LinkedIn or reach out at tripathis@qubittron.com.