Oracle's own sanctioned path into EBS can't tell you which agent did what

Oracle's E-Business Suite Adapter Capabilities documentation — the adapter Oracle Integration Cloud (OIC) uses to reach EBS, and the same adapter Oracle's own reference architecture for AI-agent access routes through — states, verbatim: “HTTP Basic Authentication is the only supported authentication security for REST services in this release.”

The username and password are set once, on the adapter connection itself, and passed through at runtime for every call. That means the credential actually reaching EBS is a single, static, shared service account — identical for every request, whether it was triggered by one employee, a different employee, or an autonomous agent acting on either one's behalf.

EBS's own audit columns — CREATED_BY and LAST_UPDATED_BY, the fields an auditor or control owner actually pulls to answer “who did this” — record whatever identity authenticated the call. On this path, that identity is always the integration account, never the human who asked or the agent that acted. An agent could execute a real write inside EBS through Oracle's own sanctioned interface, and EBS's own evidence trail would show the same generic service account it shows for every other integration call ever made through that connection — a present-tense limitation in shipped Oracle documentation, not a roadmap gap Oracle has promised to close.

Oracle's own A-Team — its solution-architecture group — published a proof of concept routing a Fusion AI Agent through OIC's hosted MCP server and this same EBS Adapter — explicitly “the proposed pattern,” in Oracle's own words, not a shipped product. The only capability it actually demonstrates is a read: a single identity lookup, in 6.24 seconds. Oracle's own adoption guidance describes usage expanding “as tool contracts, approval rules, and observability mature” — Oracle conceding, in its own materials, that those three aren't mature yet.

Two honest caveats worth carrying alongside the finding above, so this doesn't overstate the case: identity propagation does appear to be possible on other OIC adapters, and EBS's own Integrated SOA Gateway reportedly supports token-based authentication in addition to Basic Auth. Neither was independently verified end-to-end for this piece. That cuts the other way from a marketing claim — it means the constraint described above is a property of the specific adapter and integration path Oracle's own reference architecture uses today, not an unfixable law of EBS itself. It's an argument for building a better path deliberately, not evidence the gap is already closed.

On the write side specifically, this adapter reaches PL/SQL APIs, concurrent programs, Java/OAF services, and interface tables — but not Oracle Forms, CUSTOM.pll, or Forms personalizations, where a large share of a customized R12 instance's real validation logic actually lives. Whether a given write is fully governed ends up depending on which interface an integration admin chose to expose, and whether its validation chain actually matches the one your Forms UI enforces — instance-specific configuration knowledge no Oracle product resolves for you.

“Governed by the vendor” and “attributable to a specific actor” are two different claims, and it's worth asking any vendor — Oracle included — which one they're actually making for a given integration path. A written policy about who's allowed to do what is necessary but not sufficient if the system underneath it can't distinguish one caller from another. This is exactly the gap Tioga's Oracle EBS engagement is built to close: a governed write-path that preserves per-actor identity through EBS's own application logic layer, instead of collapsing every call into one shared account.