A vendor's governance module is the vendor's evidence about itself

Forrester's Predictions 2026 says half of enterprise ERP vendors will launch autonomous governance modules — combining explainable AI, automated audit trails, and real-time compliance monitoring. It is a prediction, dated November 2025, not a description of what ships today, and it is worth planning around rather than arguing with. If your ERP vendor governs the agents that run inside its platform, use it.

A vendor module governs the agent activity it hosts, inside its own estate. That is real value, and no one else is better placed to do it. But its audit trail is produced by the same platform whose behavior it describes. For a control owner or an auditor, that is the platform's account of itself — useful, and one input rather than the whole record.

Two further limits follow from where the boundary sits. A write that reaches the system through a path the vendor did not host — a third-party MCP server, an RPA script, a call from another vendor's platform — is outside the module's field of view. And a write that crosses systems has an approval trail that ends at the edge of whichever platform started it.

SAP's Architecture Center page on third-party MCP access to SAP solutions (last updated June 8, 2026) says that the protocol specification is still maturing, with security, identity and governance requirements for enterprise deployments “not yet fully addressed.” SAP describes its own MCP Gateway as its answer for its own path. For customers and partners who build custom or third-party MCP servers, the same page assigns the controls to them — token exchange, input validation, rate limiting, circuit breakers, secrets management, and “log every tool invocation including caller identity” — and states that operational responsibility rests “entirely with the customer or partner deploying it.”

That is a candid and reasonable statement of where a vendor's responsibility ends. It is also a description of the layer a buyer has to build or buy separately. On the Oracle side, Oracle's own E-Business Suite adapter documentation states that HTTP Basic authentication is the only supported option for REST services in that release, so on that path every agent write reaches EBS under one shared service account. The limit belongs to that adapter, not to EBS or to Oracle's roadmap, and it is a good example of a vendor's sanctioned path leaving the attribution question open.

1. Whose identity does the target system's own audit log record for an agent write — the agent's, the requester's, or a shared integration account?
2. Can the evidence be exported in a form a control owner or auditor can read without logging into the vendor's console?
3. Does it cover writes that arrive through paths the vendor did not host, such as third-party MCP servers, RPA, or another platform's agent?
4. What happens when an approval is denied or times out — and has anyone tested it?
5. Who checks that the module's controls behave as described, and does that person work for the vendor?

Use the vendor's module for what it governs. Keep whatever AI gateway or agent-security control plane you already run. Then close the part neither can vouch for on its own: that the write reached the system through its own application logic, that the system's native log attributes it, and that one record shows what was proposed, what policy ran, who approved, and what happened.

Tioga does not replace a vendor module or a control plane. It scopes and builds that last layer — see the agent action evidence map for what such a record should contain, and the free write-path exposure check for a five-minute read on your own write path.