AI agents are beginning to support enterprise workflows that go beyond drafting, summarizing, or answering questions. In agentic applications, including Oracle AI Studio and Oracle SaaS custom-built agentic applications; an agent may retrieve data, call tools, interact with application programming interfaces, or help initiate business processes. That creates an important security question: how should access, actions, approvals, and oversight be governed when software can act on behalf of a workflow?
Responsible AI is often discussed through governance, ethics, privacy, transparency, compliance, and human oversight. One of its most important operational foundations, however, is AI security. ISO/IEC 42001 adopts a management-system structure aligned with ISO management-system standards such as ISO/IEC 27001, reflecting how organizations are increasingly treating AI governance and security as connected enterprise disciplines. This focus is becoming more urgent as AI moves into production environments. In McKinsey’s 2025 State of AI survey of 1,993 participants, 51% of respondents from organizations using AI said their organizations had experienced at least one AI-related negative consequence.
In software as a service environment, AI security depends on shared responsibility. Oracle provides platform controls and security capabilities that can help support defense-in-depth, while customers govern how agents access data, use tools, trigger workflows, and require oversight.
For AI agents, shared responsibility is where platform controls and agent design meet.
Taxonomy of AI Security Threats
Emerging AI-security standards and draft specifications, including ISO/IEC FDIS 27090, and European CEN/CENELEC draft work on cybersecurity specifications for AI systems, are converging around common threat categories. These include data poisoning, evasion, model inversion, model extraction, prompt injection, and agent/tool abuse.
These threats can affect distinct layers of the AI lifecycle, including training data, the model itself, the inference path, or the surrounding tools, integrations, and agentic components. For enterprise AI agents, this surrounding architecture is especially important because many practical threats come from what the agent is allowed to access or do.
Oracle Cloud Applications are supported by cloud assurance programs and third-party attestations that vary by service, region, and scope. Customers should consult the Oracle Cloud Compliance page for the applicable list. Oracle’s Cloud Compliance page also references the Cloud Security Alliance (CSA) AI STAR, which is based on the CSA AI Controls Matrix (AICM), the AI-CAIQ questionnaire, and alignment with international standards such as ISO/IEC 42001.
How Oracle platform controls contribute to defense-in-depth against common AI attack patterns:
| AI security threat pattern | Primary risk | Relevant Oracle control areas and shared-responsibility considerations |
| Data poisoning / backdoors | Compromised training, fine-tuning. | Data/source integrity controls, tenant isolation, approved data sources, secure development practices, and dataset lineage or versioning where applicable. Role-based access control (RBAC) and access-management principles such as need to know, least privilege, and segregation of duties may also help reduce exposure. |
| Prompt and output injection | User or retrieved content overrides instructions. | Security-reviewed prompts where applicable, prompt-injection testing, input-boundary testing, guardrails, content moderation, and customer-side validation of retrieved or user-supplied content. |
| Model exfiltration, inversion, theft | Loss of model IP, parameters, or exposure of sensitive training signals. | Model hardening, adversarial threat analysis, access controls, tenant isolation, and monitoring controls where applicable. |
| Evasion and sensitive output | Manipulated inputs or outputs, leakage, or non-compliant behavior. | Response scoring, accuracy and toxicity checks, risk reviews, monitoring, human oversight, and post-deployment guardrail evaluation where applicable. |
| Agent / API abuse | Agents overuse credentials, tools, integrations, or production privileges. | MFA for administrators and privileged users; scoped workload identities or tokens for agent/tool execution; least privilege; secure configuration baselines; API review; consolidated logging; monitoring; and change validation before rollout. |
For SaaS agents and custom-built agents, many practical risks can arise not from the model alone, but from the actions the agent is allowed to take. Important design questions include which data the agent can retrieve, which tools it can invoke, which workflows it can trigger, and whether high-impact actions require human approval.
A useful distinction is whether an agent is advisory, assistive, or action-taking. As the business impact of the action increases, scoped permissions, approval gates, logging, monitoring, and rollback planning become more important.
An External Incident Illustrating Why Agent Permissions and Controls Matter
AI systems, whether powered by agentic components, generative models, or both, can behave in ways that are difficult to predict. This has important security implications when agents can use tools, credentials, integrations, or production data.
A recent publicly reported AI-agent incident illustrates a broader security lesson: AI-agent security cannot be limited to the platform layer. It also depends on how agents are designed, permissioned, monitored, and reviewed. In that incident, an autonomous coding agent reportedly used an over-scoped token outside the intended context and deleted production data and backups.
The broader lesson is simple: prompts and policies alone are not control boundaries. When an agent is optimized only for task completion, the surrounding architecture matters. Board credentials, destructive APIs, or weak environment segregation or limited review gates can increase operational risk.
Oracle’s AI-CAIQ and Cloud Compliance materials describe infrastructure-level and AI assurance control themes, rooted in ISO/IEC 27001, ISO/IEC 27002, CSA STAR, CSA AI STAR, and related security principles. These themes can support likelihood reduction, blast-radius limitation, detectability, and recovery. The examples below should be treated as control themes, not a complete list or a universal product guarantee:
- Data and environment segregation: Oracle compliance materials describe control areas related to tenant isolation, data-handling boundaries, and production/non-production separation where applicable.
- Identity and tool access: Oracle control materials describe identity and access-management principles aligned with least privilege and role-appropriate authorization.
- Supply-chain controls: Oracle describes formal supply-chain security and third-party governance practices in its compliance and assurance materials.
- Change governance: Oracle compliance materials describe change-management controls related to approval, validation, testing, and logging for production changes where applicable.
- Monitoring and logging: Oracle assurance materials describe monitoring and logging control themes that can support investigation, detection, and operational oversight.
- Backup and recovery: Oracle compliance materials describe business-continuity and recovery controls that can help reduce data-loss impact in the event of an incident, subject to the applicable service and configuration.
Where Shared Responsibility Decides the Outcome
As noted in the link, a decisive security outcome depends on shared responsibility. Oracle offers platform controls, backed by assurance programs where noted in the link, and security capabilities that can support defense-in-depth for AI-agent adoption. However, secure and resilient outcomes for Oracle AI Studio, Oracle SaaS Agents, and other enterprise agents also depend on how customers configure identities, data access, tools, workflow permissions, approval gates, monitoring, and recovery.
That may include using human-in-the-loop review for higher-impact agent actions where appropriate, scoping role and API permissions architecturally before runtime, considering applicable CIS Benchmarks for Oracle SaaS and Oracle Cloud Infrastructure (OCI) where relevant, and using available observability and monitoring capabilities to help detect, investigate, and govern agent behavior.
Oracle’s certifications, as applicable, AI-CAIQ documentation, and platform controls can help provide a defense-in-depth foundation against the AI threat landscape. Responsible AI can also depend greatly on a customer choice one layer above the platform: whether agents are designed with security in mind, scoped identities, deliberate controls, and clear human checkpoints, or with broader access and fewer review gates.
When these two elements reinforce each other, platform controls below and properly configured agents above, organizations can better manage risk and support a more resilient security outcome.
Conclusion
Together, Oracle’s platform controls and customer-configured agent governance capabilities can help establish a stronger foundation for secure, controlled, and observable AI-agent adoption in the enterprise.
As AI agents become part of more business workflows, organizations can continue strengthening this foundation by reviewing relevant Oracle Cloud Compliance resources and aligning agent permissions, tool access, approvals, monitoring, and recovery practices with their shared-responsibility model.