Let Agents Act on OCI: Add Runtime Governance to the OCI Enterprise AI Sandbox

Agents have moved from answering questions to taking actions. They run code, call tools, change records, and send email. That is where their value is, and it is also where the risk is. Oracle made OCI Enterprise AI Sandbox generally available in October 2026 with a clear promise: let your agents act, safely, inside an isolated, policy-controlled boundary.

We wanted to know what it takes to let those agents act on real systems in an enterprise. So we built the full stack in an OCI tenancy: the sandbox, OCI Identity Domains, OCI Guardrails, OCI Generative AI, Oracle Kubernetes Engine (OKE), and Traefik Hub as the one path out of the sandbox. Then we tried to make an agent misbehave. This post walks through what we built, what broke, and what stopped it.

Ask 4 questions before an agent acts

Before an enterprise lets an agent touch a production system, it needs answers to 4 questions:

1. Where does the agent's code run?
2. Who is the agent?
3. Is the text safe?
4. What is this agent allowed to do, right now, with these arguments?

OCI answers the first 3 with strong building blocks. The fourth question is different in kind, because the answer depends on the action itself: which agent is calling, which tool, with which arguments, on which model, and within which budget. That is runtime governance, and it decides what actually happens. To work, it has to sit in the path of every model, tool, and API call.

Start with what OCI already answers

Where the code runs. OCI Enterprise AI Sandbox gives each task its own isolated runtime with its own workspace. A sandbox lives for at most 48 hours, and when it stops, its workspace is gone. Networking is a project-level decision: each project has one outbound policy, either managed by the service or routed through a subnet and up to 5 network security groups (NSGs) in the customer's own VCN. Code inside a sandbox can call OCI services with a resource principal that IAM policies scope to the project.

Who the agent is. We gave each agent its own client-credentials application in an OCI Identity Domain. The orchestrator, which runs outside the sandbox, fetches a 15-minute token for the agent and passes it in when it creates the sandbox, so the agent's secret never enters the runtime. For long tasks, the orchestrator refreshes the token: a 19-minute task stayed authorized, and the first use of an expired token was refused.

Whether the text is safe. OCI Guardrails checks content for harmful material, prompt injection, and personal data.

Each of these is a strong building block, and each does the job it was designed for. The scope of each one matters for what comes next. The sandbox's own identity is scoped to a project, and so is its egress policy. Many agents with different permissions can share a project, so the project boundary can't say what each agent may do. That decision needs the agent's identity and the action, on every call.

Watch a poisoned runbook pass every check

We gave an agent a realistic task: follow the Q3 operations runbook, then summarize it for leadership. One step in the runbook was the attack. Written like routine operations, it told the agent to purge the customer table by deleting 100,000 rows and to email confirmation to an outside audit address.

We first ran it on a path that checked identity and nothing else. The agent ran in the sandbox, with a real Identity Domain token, and called an OCI Generative AI model (OpenAI's gpt-oss-20b). It deleted 100,000 customer rows and sent the email. We repeated the run with Anthropic's Claude Haiku 4.5, and it did the same.

"Every check did its job, and the agent still did exactly what the runbook said."

Content scanning scored the runbook as clean, as expected. A well-formed instruction to delete records contains nothing a content filter should object to, because the danger lies in the action, not in the words. The sandbox kept the agent contained, its identity was real, and the text was clean. No layer had been asked whether this agent should delete 100,000 rows.

Give the sandbox one destination: Traefik Hub on OKE

The sandbox makes the next step straightforward. With custom networking, the project's egress leaves through a subnet in the customer's VCN, under the customer's NSG rules. We allowed exactly one destination: Traefik Hub's internal load balancer on port 443. From inside the sandbox, the internet, package registries, and even OCI's own model endpoint were unreachable. Hub was the only door.

Traefik Hub ran on OKE as an AI Gateway and MCP Gateway. The same Hub is also an API Gateway, so an agent's calls to REST APIs can take the same path. Together, the three make up the Triple Gate pattern: one gate each for models, tools, and APIs, on one path. On each call, Hub applies its checks in a fixed order:

1. Validate the agent's token: signature, issuer, and audience.
2. Apply the tool or model policy for that identity.
3. Call OCI Guardrails on the input.
4. Forward the call with the provider key Hub holds, so no long-lived key enters the sandbox.
5. Check and mask the output.
6. Record the access entry in the transparency log.

The token check uses the Identity Domain's signing keys supplied inline, with the issuer and audience pinned, and it forwards the agent's name for policy and evidence:

# Traefik Hub Middleware, spec.plugin (excerpt): the agent's token check
jwt:
  jwksFile: '{"keys":[ ...contents of
    https://idcs-<domain>.identity.oraclecloud.com/admin/v1/SigningCert/jwk... ]}'
  claims: >-
    Equals(`iss`, `https://idcs-<domain>.identity.oraclecloud.com:443`)
    && Equals(`aud`, `https://hub.oci-lab.traefik.ai/`)
  usernameClaim: client_name
  forwardHeaders:
    X-Agent: client_name

We supplied the keys inline because the Identity Domain's key endpoint marks its responses as not cacheable (Cache-Control: no-cache, no-store, must-revalidate). Hub honors that, so with a key URL it would fetch the keys on every request. With the keys inline, the token check alone ran at about 300 requests per second in the cluster. Refresh the inline keys when the domain rotates its signing certificate.

Write the policy that fits your business

With every tool call passing through Hub, policy can look at the action itself. Hub's MCP Gateway evaluates each tools/call against the caller's token and the tool's arguments, using task-based access control. This is the policy we wrote for the lab:

# Traefik Hub Middleware, spec.plugin (excerpt): the lab's tool policy
mcp:
  policies:
    - match: >-
        Equals(`mcp.method`, `tools/call`)
        && Equals(`mcp.params.name`, `delete_records`)
        && Gt(`mcp.params.arguments.count`, `10`)
      action: deny
    - match: >-
        Equals(`mcp.method`, `tools/call`)
        && OneOf(`mcp.params.name`, `delete_records`, `send_email`)
        && !SplitContains(`jwt.scope`, ` `, `mcp.write`)
      action: deny
    - match: >-
        Equals(`mcp.method`, `tools/call`)
        && Equals(`mcp.params.name`, `lookup_customer`)
        && !Equals(`jwt.client_name`, `finance-agent`)
      action: deny
    - match: >-
        Equals(`mcp.method`, `tools/call`)
        && Equals(`mcp.params.name`, `send_email`)
        && Contains(`mcp.params.arguments.to`, `@ourcompany.com`)
      action: allow
    - match: >-
        Equals(`mcp.method`, `tools/call`)
        && Equals(`mcp.params.name`, `send_email`)
      action: deny
  defaultAction: allow
  listPolicies:
    - match: >-
        Equals(`mcp.params.name`, `lookup_customer`)
        && !Equals(`jwt.client_name`, `finance-agent`)
      action: hide

Deletes are capped at 10 rows. Destructive and outbound tools need a write scope in the agent's token. Customer lookups belong to the finance agent, and other agents don't even see that tool in their tool list. Email goes only to company addresses. These limits are ours, chosen for the test, and your security team writes the rules that fit your business. One production note: Contains is a substring match, so for real recipients, list the allowed addresses with OneOf or send email through a tool that only accepts internal recipients.

On this governed path, the same agents reached the same runbook step, and Traefik Hub refused the delete and the email in 62 to 109 milliseconds, measured from inside the sandbox, before anything ran. The agents reported that the actions were blocked and stopped. The decision didn't depend on whether the text looked suspicious, because Hub evaluated the action.

Bring OCI Guardrails to tool traffic

Content safety still matters, and this is where Oracle's building block and Hub reinforce each other. Hub called OCI Guardrails (the ApplyGuardrails action) on prompts, on tool arguments, and on tool results. That extended Oracle's content safety to MCP tool traffic and to models hosted outside OCI. In the lab, OCI Guardrails caught a prompt injection hidden inside a document a tool returned and stopped a harmful request before any model saw it.

We also learned to choose between blocking and masking. Blocking on every personal-data hit stopped legitimate work, such as an email to a colleague. Hub's Content Guard masked contact details in tool results instead, so routine work kept moving. To make masking mandatory for every team, put it on a parent router and let each team's routes attach to it as children.

Govern models and spend on OCI Generative AI

Agents also need models, and an enterprise needs to know which agent can use which model and at what cost. The same door decides that. Hub gave each agent its own allowlist of OCI Generative AI models and failed over between them on errors and rate limits, so when one model was unavailable, requests moved to the next with no change to the agent. Each agent had its own token budget and a dollar cap, both enforced at the gateway. Teams that also use other model providers apply the same identity rules, guardrails, and budgets from the same control point. All 27 checks in that phase passed.

Prove what happened, inside OCI's own observability

When someone asks what an agent did, and why, the answer has to hold up. We turned on Hub's transparency log, which hashes every Hub log line and access record into an append-only Merkle tree with signed checkpoints. We verified the checkpoints independently with the public key, and a tampered checkpoint failed verification. The access records name the agent and the outcome, such as the finance agent's refused delete operation.

Evidence is most useful where operations teams already work. Traefik documents 2 OCI integrations for Hub on OKE. Hub's access logs can be collected into OCI Log Analytics through OCI's Kubernetes monitoring and a Traefik log source, with a ready-made dashboard. Hub's metrics and traces can go to OCI Application Performance Monitoring over OpenTelemetry. That puts agent decisions next to the rest of a team's OCI data, where they can search, chart, and alert on them.

Publish agents without exposing the sandbox

Sooner or later, an agent serves someone else: a partner, an application, or another agent. A sandbox can publish a port at a URL, and Oracle's guidance is to treat that URL as sensitive and add your own authentication. In our tenancy, a published port answered anyone with the URL by default, and an OCI_IAM mode limited it to OCI-signed requests, which suits OCI-internal callers. Outside consumers need more: their own identity, subscriptions, rate plans, and a stable address that outlives short-lived sandboxes.

So we published the agent rather than the sandbox. The agent ran as a long-lived service on OKE, behind Traefik Hub API Management, and ran its code in a sandbox with no published ports and could reach only Hub. Partners called it with an API key, and OCI users called it with their Identity Domain token. Plans decided who got in and how often. In the lab, an unsubscribed consumer received a 403, a plan of 3 requests per minute returned 3 successes and then 2 429s, and the signed log named each consumer. All 8 checks passed.

See how the pieces fit

Each layer does the job it was designed for, and together they let enterprises put agents to work on real systems in OCI.

Oracle provides the building blocks: a safe place to run, an identity for every agent, and content safety. Traefik Hub adds unified runtime governance for models, tools, and APIs, on the one path every model, tool, and API call takes.

Get started on Oracle Cloud

Traefik Hub already runs on Oracle Kubernetes Engine and is available in the Oracle Cloud Marketplace. Start with one agent, one MCP server, and one model behind Hub, make Hub the sandbox project's only destination, then add policy as your agents take on more work. Watch the video, under 4 minutes, for the whole story, and talk to us to walk through the configuration that ran in this lab.