A practical approach to agent permissions, human approval, and accountable execution on Oracle Cloud Infrastructure.
Imagine an operations analyst investigating suspicious activity on a cloud workload. An AI agent reviews the evidence and recommends stopping a compute instance. The analyst checks the recommendation and clicks Approve.
A moment later, the agent changes its plan. It selects a second instance or retries a request whose outcome is unclear. Does the original approval still apply?
That is a question CISOs should settle before an agent can change a production system. Connecting an agent to enterprise tools gives software the ability to act with someone else’s authority. The organization needs to decide how that authority is granted, how far it extends, and what happens when the plan changes.
My starting point is simple: an approval should identify the action, the resource, and the conditions under which execution is allowed. The system should enforce that decision even when the agent produces an unexpected recommendation.
Decide what the agent is allowed to do
An incident-triage agent does not need the same authority for every part of its job. Reading approved workload metadata may be routine. Stopping an instance affects availability. Changing access policies could affect the security of the entire environment.
Give those activities different rules. Start with a small set of permitted operations and name the person responsible for each decision. The following is an illustrative policy for one incident-response workflow.
| Agent activity | Authority required | Operating boundary |
|---|---|---|
| Read workload metadata | Automatic within approved scope | Selected compartments and fields |
| Recommend containment | May propose a change | No permission to execute it |
| Stop a selected instance | Approval from an authorized responder | Exact target, operation, and validity period |
| Change IAM policies or delete protected resources | Excluded from this workflow | Reject and route to the established process |
The workload owner should help set these boundaries. A security team may see a compromised instance; the business owner may know that stopping it would interrupt a critical transaction process. A useful approval brings that context into the decision.
Keep execution behind a trusted service
On Oracle Cloud Infrastructure (OCI), one implementation could use an agent application backed by OCI Generative AI, a workflow service that records and validates approvals, and separate OCI Functions for permitted operations. A database stores the request, its approval, and its execution status.
The agent proposes a structured action. Trusted application code checks the request against policy, obtains any required approval, and passes the approved request to an execution function. The executor validates it again before calling the OCI API.
In this design, the agent application cannot stop instances directly. Only the executor has that permission. Its interface accepts a defined operation and validated parameters rather than arbitrary commands. Access to invoke it must also be restricted.
OCI Functions can use resource principals to authenticate to OCI services, with dynamic groups and IAM policies defining access. Scope the executor’s permissions to the operations and resources it needs, and review other grants that could broaden its access. Oracle describes the configuration in its Functions resource-principal guidance.
There are two authorization decisions here. IAM determines what the function can do in OCI. The application determines whether the authenticated requester and approver may authorize this particular action. A function’s cloud identity does not establish that a human approved the change.
Make the approval specific enough to enforce
Consider what the analyst should see before stopping an instance: the resource name and unique identifier, environment, proposed operation, reason for the change, expected disruption, and recovery approach. Include when the approval expires. “Approve remediation” leaves too much open to interpretation.
Create a fixed action record before presenting that decision. Bind the approval to its request identifier and exact contents, including the target and meaningful parameters. If the agent substitutes a resource or expands the scope, require a new approval.
The approval service must establish the approver’s identity from an authenticated session and check their authority. A sentence in a conversation or retrieved document saying “the incident commander approved” cannot create an authorization. For higher-impact actions, the organization may require a different person to approve the request.
This is also a usability issue. Show the relevant evidence and business impact without burying the responder in a full transcript. An approval that people cannot reasonably evaluate will become a routine click.
Check again when the action runs
An approval can be valid when issued and inappropriate ten minutes later. Another responder may have handled the incident. The resource may have moved outside the approved scope, or the approver’s authority may have changed.
Immediately before execution, check that the approval remains valid and unexpired, the action still matches it, and the relevant resource conditions still hold. Keep that interval short and use conditional updates where the target API supports them. If a material condition has changed, stop and return the request for review.
Duplicate delivery needs its own control. Two workers might receive the same approved request. Use a persistent, atomic claim on the request so only one worker can begin execution. A duplicate should return the existing status.
Then plan for the awkward case: the executor submits a stop request, but the response never arrives. A timeout does not tell you whether OCI accepted the operation. Check the resource and available request information before retrying. If the outcome remains uncertain, send it for investigation. A record marked “started” is not proof that the intended change finished.
Use guardrails alongside action controls
Content inspection can help when agents read material that someone else controls. A retrieved incident report might contain instructions to ignore policy or stop every instance in a compartment.
OCI Generative AI Guardrails supports prompt-injection detection, content moderation, and detection of personally identifiable information. Teams must configure or integrate the inspection path deliberately. For on-demand inference, the ApplyGuardrails API returns results for the application to handle.
Those results add useful signals, but detections can miss an attack. A request with ordinary language can also seek an action the user is not entitled to authorize. The executor must enforce its rules regardless of the agent’s confidence or the guardrail result.
Leave a record that explains the decision
After an incident, someone will need to explain why the change happened. Keep the original request, proposed action, policy decision, authenticated approval, and execution result connected through a common request identifier. Record the relevant application, model, tool, and policy versions.
OCI Audit records activity at supported public API endpoints. Correlate the relevant cloud events with application records using available request identifiers, resource identifiers, timestamps, and execution identity. The application supplies the business explanation and approval details that a cloud API event alone cannot provide.
Protect this evidence. Separate permission to execute changes from permission to administer approval records, control access, and set retention rules. Keep enough information to reconstruct the decision without copying every sensitive document or prompt into logs.
Start with one action and try to break the rules
A useful first exercise is stopping a designated nonproduction instance after approval. Treat the architecture above as a proposed design to validate, not evidence of a completed deployment.
Test the approved request, then substitute a target, reuse the approval, let it expire, and submit the same request concurrently. Put a false claim of approval in retrieved content. Simulate a lost API response. The team should be able to show which requests were rejected, whether duplicate execution was prevented, and how uncertain outcomes were resolved.
Exercise the emergency stop as well. An application control should prevent new execution when responders disable the workflow, and fail closed if its authorization state cannot be checked. In-flight operations need separate handling. Do not rely on an IAM change taking effect immediately: Oracle documents a 15-minute resource-principal token cache for Functions and notes that policy or dynamic-group changes can take that period to appear.
For the CISO, the review can stay focused. Ask the team to show the permitted actions, the people who can approve them, and an example that connects approval to the resulting cloud operation. Then ask them to change the target and demonstrate that execution stops.
That exercise gives the organization a concrete basis for deciding how much autonomy to allow next. Begin with a task the business understands, make the delegation explicit, and expand only when the controls hold up under testing.
Before the next agent receives production access, walk one proposed action through that process. If the team cannot show exactly what was authorized and why the executed action stayed within it, that is the gap to close first.