Fusion AI Agents: Secure by Design Best-Practice Considerations 

This blog is intended as thought leadership and security best-practice considerations for organizations designing agentic applications in Oracle Fusion environments. The considerations described here help provide a framework to evaluate and plan security considerations for Fusion AI Agents and agentic applications. Applicability depends on the agent use case, product capability, licensing, deployment model, and each organization’s security and governance processes.

As organizations evaluate artificial intelligence (AI) agents across enterprise workflows, the security conversation becomes broader than model output. In Oracle Fusion environments, AI agents can help summarize, recommend next steps, and, depending on the use case and available capabilities, help initiate actions across Oracle Fusion Cloud Applications workflows. That capability can be valuable, but it also introduces important security design considerations: an agent may interact with enterprise identity, business data, application programming interfaces (APIs), and business processes.

This blog series is structured around three security areas: design, enforcement, and operations. This Part 1 focuses on design-time considerations that can help organizations evaluate risks, clarify authority and create a clearer foundation for later controls. When design assumptions are vague, runtime guardrails can become harder to evaluate, explain, reason about, and operate.

1. Consider the Agent as a Business Actor, not a Chatbot

A practical starting point is to think about an AI agent as a business actor with a defined security-oriented “job contract.” This contract can help clarify the agent’s purpose, scope, and authority model before it is connected to tools, data, or business workflows.

The job contract can include:

• Intended outcomes: the business value the agent is expected to support
• – Prohibited outcomes: actions or decisions the agent is not intended to attempt
• – Allowed tools and data domains: the systems, integrations, and information sources the agent may use
• – Human checkpoints: review or approval points that may be needed for higher-risk actions

Organizations can also consider classifying agents by business impact, using categories aligned with their risk methodology, such as:

• Low risk: informational retrieval, such as leave policy question and answer (Q&A)
• Medium risk: recommendations without direct system updates
• High risk: create or update actions on transactional objects
• Critical risk: payment, payroll, supplier banking, or regulatory actions in a Fusion context, this classification can help guide role design, data scoping, approval needs, and logging expectations. The goal is not to imply that every agent is already subject to a universal threat-modeling process. Rather, this framework can help teams assess the risk introduced by agent autonomy and decide which design considerations may apply.

As an implementation consideration, when a new tool binding is added, such as a REST API, integration flow, or document source, teams can consider whether the agent’s risk profile has changed before that capability is promoted into broader use.

•  Bind Agent Actions to Identity and Authority Context

Not all AI agents carry the same level of business risk, and not all agent actions require the same level of authority. Where the implementation supports it agent actions can be easier to evaluate when attributable to a requester, an execution principal, and the relevant authorization or approval decision.

 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. Design considerations include:

• Identifying the calling user and session context
• Binding requests to delegated authority where appropriate
• Capturing policy or approval decisions used at execution time
• Recording the principal used for downstream API calls

In Oracle environments,   Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) identity domains, and legacy Oracle Identity Cloud Service (IDCS) footprints where still present, can be part of the identity control plane. Fusion Security Console role design, including duty roles and data roles, can then help align agent capabilities with existing entitlement models.

For Fusion implementations, Oracle AI Agent Studio for Fusion Applications can support agent orchestration. 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., not an assumed platform guarantee.

3. Separate Trusted Instructions from Untrusted Content

Prompt injection risk can be viewed as a trust-boundary issue. Agentic applications may ingest user prompts, documents, email text, API payloads, or web content.  Those sources can provide useful context, but they may also contain adversarial instructions that conflict with the intended policy, business objective, or workflow boundary. Design considerations may include:

• Keeping system policy and runtime instructions separate from user-controlled content
• Treating external content as data rather than authority
• Defining conflict-resolution rules, such as policy before tool output before user request
• Reducing risk that untrusted content is treated from silently changing the agent’s objective

For example, a service-oriented agent may read a customer email and retrieve an internal escalation policy. Keeping those inputs logically segmented can help prevent external text from overriding internal policy.

For Fusion implementations, teams building custom orchestration can consider explicit context segmentation. If external text, internal policy, and tool responses are merged into one undifferentiated prompt, injection resistance can become harder to evaluate and validate.

4. Evaluate Segregation of Duties (SoD) Before Composing Workflows

SoD issues can emerge when multi-step workflows are compressed into a single conversational experience. The design question is not only whether an agent can complete the process, but whether one actor, human or agentic, is appropriate for every step in that process.

For example, supplier onboarding and payment approval may need to remain separated even if a conversational flow could technically connect both actions. Considering these constraints during design can help give later runtime enforcement a clearer policy intent to follow.

For Fusion implementations, where Oracle Risk Management, Oracle Access Governance, or equivalent enterprise controls are in use, teams can consider mapping agent capabilities to the same SoD model used for human roles. If a human workflow would raise a conflict, the analogous agent-enabled flow may merit evaluation through a similar risk lens.

5.  Build a Control Map Before Broader Use

Before broader use, teams can create a lightweight control map that links agent capabilities to concrete governance and security considerations. The goal is to clarify which controls may apply to a specific agentic use case.

• Identity: OCI IAM Identity Domains, federation, and token policies where applicable
• Entitlements: Fusion Security Console roles and data roles
• Transaction controls: Fusion approval routing or business process management (BPM) based approvals where available.
• SoD and access governance: Oracle Risk Management and Oracle Access Governance, if implemented.
• Audit: Fusion audit records and enterprise monitoring or security information and event management (SIEM) integration, where applicable.

This type of artifact helps avoid security-by-assumption. It can give reviewers a clearer view of which recommendations are implemented, which are handled through existing enterprise controls, and which remain future-state considerations.

Conclusion

Security-focused design considerations can provide a practical foundation for evaluating agentic applications. In Fusion environments, teams can consider business-risk classification, identity-aware execution, context segmentation, and SoD-aware workflow boundaries; then map those design considerations to the Fusion and OCI controls available in their environment.

In Part 2, we move from design intent to runtime enforcement: including least privilege, just-in-time (JIT) authorization patterns, tool invocation constraints, prompt-injection defenses, and human approval controls that can help support alignment with intended workflow boundaries.