Oracle AI Agent Studio Security for Oracle AI Agents and Fusion AI Agents That Act Beyond Fusion
Oracle AI Agent Studio for Fusion Applications has one of the better security models in enterprise agents: every Fusion call carries the running user's token and Fusion stays the authorization authority. That model covers Fusion. It does not follow an agent out through an MCP tool, an External REST node, a scheduled service account or an inbound email trigger, and Oracle says so in its own guidance.
Direct answer
Oracle AI Agent Studio security is strong wherever an agent calls Fusion as the signed-in user, because the running user's Fusion token carries row and data security into every Fusion action and an agent cannot see more than that user can. The gaps sit at the edges Oracle itself flags: MCP and External REST tools that reach non-Fusion systems, Workflow Agent Teams scheduled under a service account, webhook and inbound email triggers that start runs with no person present, and human approval that a builder must add. AgentShield covers those edges by checking each outbound tool call against a policy, holding high-impact writes for approval and recording the requester, the execution account and the decision together.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A finance operations team builds a Workflow Agent Team in AI Agent Studio that reads supplier emails, looks up the supplier in Fusion and updates remittance details. It runs on an inbound email trigger under a service account so that it works overnight. Inside Fusion every call is authorized, because the service account holds the roles it was given. One night an email arrives that looks like a routine supplier update and carries new bank details plus an instruction to apply them before the next payment run. Nobody was in the loop, the External REST node that also notifies the treasury system did exactly what the agent asked, and the audit record shows the service account made the change, not whether any human with that authority would have.
How AgentShield handles it
Leave Oracle in charge of what it governs well: Fusion identity, role-based run access, object-level builder privileges, data security on every Fusion call, and METRO tracing. Put AgentShield on the paths Fusion does not govern. Register the MCP servers and external REST endpoints your agent teams call behind the AgentShield gateway, write a policy per tool and per trigger type (for example, email-triggered runs may read but may not change bank or payment data), hold writes above a threshold for a named approver, and inspect retrieved email, document and web content for injected instructions before it reaches the model. Every decision is written with the requester, the execution account, the tool, the inputs and the verdict, so an auditor can answer the question Oracle raises: was this action appropriate for the authority behind it.
The controls
The controls that secure what Oracle AI Agent Studio agents may change outside Fusion, and under whose account.
How Oracle AI Agent Studio secures Fusion AI agents, and where that model stops
Oracle AI Agent Studio for Fusion Applications is Oracle's builder and runtime for AI agents inside Fusion Cloud ERP, HCM, SCM and CX, and Oracle includes it for Fusion Cloud customers at no additional cost. It launched in March 2025, gained an AI Agent Marketplace with partner-built agents and support for external LLMs from OpenAI, Anthropic, Cohere, Google, Meta and xAI in October 2025, and added the Agentic Applications Builder in March 2026. In July 2026 Oracle announced an AI-native builder experience that lets developers build agent teams from Visual Studio Code, the command line and coding assistants such as Codex and Claude Code, plus agent-to-agent interoperability so third-party and custom agents can take part in Fusion workflows.
The security model underneath all of this is identity propagation, and Oracle's Fusion Center of Excellence describes it well. A user signs in through Fusion's identity service, invokes an agent team they are allowed to run, and the agent calls Fusion REST resources with that user's context. Fusion then applies the user's roles, privileges and data-security policies. In Oracle's words, "The API does not simply trust the agent," and if a manager asks about a worker outside their hierarchy, "using an agent does not expand his access. Fusion remains the authorization authority."
That is a genuinely good design, and it is better than what most agent platforms offer. The honest question for a security team is what happens when an agent leaves the part of the system where Fusion is the authority. The agent team building blocks answer it. A Supervisor Agent Team can carry Business Object, Deep Link, MCP and Files or RAG tools. A Workflow Agent Team can use External REST, Connector and Send Email nodes and can be started by chat, a webhook, an inbound email or a schedule. Credentials for outside systems are stored as shared resources.
| AI Agent Studio surface | Who or what starts it | Who authorizes the action | What to watch |
|---|---|---|---|
| Business Object tool or node calling Fusion | A signed-in user in chat | Fusion, using the running user's token and data security | Well governed. The agent cannot exceed the user's own access |
| MCP tool on a Supervisor Agent Team | Whatever started the run | The MCP server and the credential it was given, not Fusion | Fusion data security does not apply to the target system |
| External REST and Connector nodes | A workflow step | The stored credential for the outside system | Oracle says identity context across these boundaries needs explicit design |
| Scheduled or webhook Workflow Agent Team | A schedule or an HTTP call, no person present | The service account the team runs under | The run has the service account's reach, not a requester's |
| Inbound email trigger | Anyone who can send the mailbox an email | The execution identity of the team | The email body is untrusted input driving a privileged run |
The first row is where Oracle's model shines, and if your agents only live there you may not need anything else. Rows two to five are the ones this page is about.
What Oracle says customers must secure themselves in AI Agent Studio
Oracle is unusually direct about shared responsibility for agents, which makes the gap easy to describe without guessing. Three statements from Oracle's own security guidance matter most.
External tools are an implementation question, not a platform guarantee. Oracle's secure-by-design guidance for Fusion AI agents says that "Custom tool integrations may still need explicit design to preserve identity context across agent-to-API boundaries. This is an implementation consideration, not an assumed platform guarantee." When an agent calls your treasury system, a bank portal, a ticketing tool or a partner API through MCP or External REST, the user's Fusion token does not travel with it and Fusion is not the one saying yes.
Service accounts erase the requester. Oracle notes that "A builder can schedule a Workflow Agent Team to run under a service account, but scheduling requires an additional privilege," and its design guidance warns: "If an agent uses an over-privileged technical account without preserving requester context, audit trails may show what happened but not whether the action was appropriate for the user's authority." A scheduled close task or an overnight collections agent is exactly this shape.
Prompts and guardrails are not the boundary. Oracle's identity and security post puts it plainly: "Prompts and guardrails help shape behavior, but they do not replace the identity, role, and data-security model already protecting Fusion." Oracle's shared-responsibility post goes further: "prompts and policies alone are not control boundaries." That is correct, and it means the question for anything outside Fusion is what does the enforcing.
| Control | What Oracle provides | What is left to you |
|---|---|---|
| Who can build and run agents | Role-based access per agent team, pillar and object-level builder privileges | Keeping builder, run and service-account access separate, as Oracle recommends |
| Data access inside Fusion | Running user's token with native row and data security | Testing with users of different scopes, including a negative test |
| Actions in non-Fusion systems | Credentials, Connectors, MCP and External REST building blocks | Per-tool policy, identity context and limits on what each call may change |
| Human approval | A Human Approval workflow node, and approval for transactional POST, PATCH or DELETE actions | Deciding which actions need it and adding it, since it is not on by default for every write |
| Prompt injection | Guardrails that shape behavior, plus security-reviewed templates | Treating email, documents and retrieved content as data, not authority |
| Monitoring | METRO runs, metrics, tracing and evaluations | Restricting trace access, since Oracle advises treating traces as business data, and getting events into your SIEM |
None of this is a criticism of Oracle. It is the same boundary every serious platform draws: Fusion governs Fusion. What changed in 2026 is how much of an agent's work happens elsewhere, because agent-to-agent interoperability, MCP tools and marketplace agents all exist to reach outside the suite.
Five Oracle AI agent patterns and the risk each one carries
Oracle's own design guidance suggests classifying agents by business impact and treats payment, payroll, supplier banking and regulatory actions as critical. Here is how that lands on the patterns US Fusion customers are actually building.
| Agent pattern | Typical tools | Main risk | Control that matters most |
|---|---|---|---|
| Employee and manager self-service in HCM | Business Object reads as the signed-in user | Low. Fusion data security already scopes it | Oracle's own controls. Buy nothing extra |
| Supplier inquiry and remittance agents in ERP | Inbound email trigger, Business Object update, Send Email | Injected bank-detail changes arriving by email | Human approval on any bank or payment field, content inspection on the email |
| Collections and cash application | Scheduled team, External REST to a bank or payment provider | Service-account writes outside Fusion with no requester | Per-tool policy on the external call and an attributed record |
| Supply chain exception handling | MCP tools into carrier, WMS or supplier portals | Order changes in systems Fusion does not govern | Allowlisted MCP tools and value thresholds |
| Marketplace or third-party agents | Partner-built agents, agent-to-agent calls | Code and prompts you did not write acting with your credentials | Least-privilege credentials plus runtime checks on every outbound call |
The supplier remittance row is the one that should worry a US controller. Business email compromise against vendor bank details is already one of the most expensive fraud patterns in accounts payable, and an agent that reads supplier email and has write access to supplier banking turns a phishing email into a direct change request. Oracle's guidance on segregation of duties applies here too: supplier onboarding and payment approval "may need to remain separated even if a conversational flow could technically connect both actions." If your Fusion instance uses Oracle Risk Management or Oracle Access Governance, map agent capabilities onto the same segregation rules you use for people.
Prompt injection is not hypothetical in these patterns. Oracle's guidance says agentic applications "may ingest user prompts, documents, email text, API payloads, or web content" that "may also contain adversarial instructions," and recommends "Treating external content as data rather than authority." Our prompt injection protection does that at the gateway: it inspects the email, attachment or retrieved text for instructions aimed at the model before the agent acts on it.
Oracle native controls compared with a runtime layer for Fusion agents
A fair comparison has to start with what you already own. Fusion customers get AI Agent Studio, its security model and METRO without an extra license, and several of the needs below are fully met by configuring them properly.
| Need | Oracle AI Agent Studio alone | With AgentShield added |
|---|---|---|
| Fusion data access limited to the running user | Yes, natively | No change. Oracle already does this well |
| Who may build and run each agent team | Yes, role-based and object-level | No change |
| Policy on MCP and External REST calls to non-Fusion systems | Depends on how each integration is built | Per-tool allow, deny and hold rules at the gateway |
| Different rules for chat, email, webhook and scheduled runs | Through agent design and separate service accounts | Policy can key on trigger type, so email-started runs get tighter limits |
| Approval for high-impact writes outside Fusion | Human Approval node where the builder adds it | Approval enforced on the call itself, regardless of which team made it |
| Record of requester, execution account and decision together | METRO traces the run | Tamper-evident record per action, exportable to your SIEM |
| Consistent controls across Fusion, Microsoft, AWS and custom agents | Fusion only | One policy set across platforms |
Two of those seven rows say buy nothing, and we mean it. If your agent teams are self-service assistants that read Fusion data as the signed-in user, Oracle has you covered and adding a gateway would be cost without benefit. The case for a runtime layer starts when an agent team holds credentials to something outside Fusion and can change it, or when it runs on a schedule, a webhook or an email with nobody watching.
Oracle's September 2026 security messaging, which SiliconANGLE summarized as an aim "to enforce authorization regardless of which application, user or agent reaches the database," points the same direction from the other side: controls belong on the path the action takes, not in the prompt. For Oracle data that path is the database. For your bank, carrier portal or ticketing system, that path is the outbound call.
How to put AgentShield in front of Oracle AI Agent Studio tools
Setup changes where an agent team's outbound connections point, not how the team is built. You keep building in AI Agent Studio exactly as before.
- Inventory the edges. List every MCP tool, External REST node, Connector and stored credential across your agent teams, and note which teams run on a schedule, a webhook or an inbound email. That list is your real attack surface.
- Route outbound calls through the gateway. Register the MCP servers behind the AgentShield MCP gateway and point External REST endpoints at the AgentShield proxy. Fusion Business Object calls stay direct, because Fusion already governs them.
- Write policy per tool and per trigger. For example, allow carrier status reads for any run, allow shipment changes only under a set value, and deny any change to supplier bank details from an email-triggered run. Our AI agent permissions management is where those rules live.
- Hold the critical actions. Payments, bank detail changes, payroll adjustments and anything irreversible pause for a named approver with the full inputs in front of them. See human approval for AI agents for how the hold works.
- Record it for the auditor. Each decision captures the requesting user where one exists, the execution account, the tool, the arguments and the verdict in a tamper-evident audit trail, which answers the question Oracle says a bare service-account log cannot.
If your Fusion agents sit alongside agents on other platforms, the same policy applies across them. Teams running agents in Microsoft 365 as well should read our Copilot Studio security page, and finance teams with broader agent programs will find the controls regulators ask about on the financial services AI agents page. For agents that separate a supervisor from worker agents, as Oracle's reasoning pattern does, multi-agent security covers how trust passes between them.
FAQ
Common questions about oracle ai agent studio security.
Is Oracle AI Agent Studio secure?
Inside Fusion, yes. Agents call Fusion with the running user's token, so Fusion roles, privileges and data security decide what they see, and an agent cannot exceed the user's own access. The risk sits outside Fusion: MCP and External REST tools, service-account schedules and email triggers, which Oracle says customers must design and secure themselves.
Does Oracle AI Agent Studio cost extra?
No. Oracle includes AI Agent Studio for Fusion Applications for Fusion Cloud customers at no additional cost, as reported when it launched in March 2025. Using external LLMs or partner agents from the AI Agent Marketplace can carry their own costs, and third-party security tools such as AgentShield are licensed separately.
Can Oracle AI agents access data a user is not allowed to see?
Not through Fusion. Oracle states that using an agent does not expand a user's access and that Fusion remains the authorization authority, so a manager asking about a worker outside their hierarchy gets nothing extra. The exception is a team run under a service account, which carries that account's access rather than a requester's.
Does Oracle AI Agent Studio support human approval?
Yes. Workflow Agent Teams have a Human Approval node, and Oracle notes that transactional POST, PATCH or DELETE actions can require approval before they are committed. It is something builders add, not a default on every write, and Oracle recommends adding human approval before consequential business updates.
Can Oracle AI Agent Studio agents use MCP servers?
Yes. Supervisor Agent Teams can carry MCP tools alongside Business Object, Deep Link and Files or RAG tools. When an MCP tool reaches a non-Fusion system, Fusion data security does not govern that system, and Oracle says identity context across agent-to-API boundaries needs explicit design by the customer.
What is the biggest security risk with Oracle Fusion AI agents?
Unattended runs that can change something outside Fusion. A Workflow Agent Team on an inbound email or schedule trigger, running under a service account, with an External REST or MCP tool that writes to a bank, carrier or ticketing system, has no person present and no requester context when an injected instruction arrives.
How do I monitor Oracle AI Agent Studio agents?
Oracle provides METRO for runs, metrics, tracing and evaluations, with visibility scoped by role, and advises treating traces as business data. For decisions on outbound calls and a record that ties requester, execution account and verdict together, add a runtime layer that logs each action and exports it to your SIEM.
Does AgentShield work with Oracle AI Agent Studio?
Yes, on the outbound path. You route the MCP servers and External REST endpoints your agent teams call through AgentShield, which checks each call against your policy, holds high-impact writes for approval, inspects email and document content for injected instructions and records every decision. Fusion Business Object calls stay under Fusion's own controls.
More use cases