“Human in the loop” is becoming a standard requirement for enterprise AI. Oracle’s own guidance describes adding approval steps before an agent performs important actions, and Oracle recommends human oversight for API operations that can change state.
But the phrase leaves an important question unanswered. What, exactly, did the human approve?
If an AI agent displays a friendly summary, receives an approval and then rebuilds the request with a different target or payload, the human did not approve the operation that ran. If a plan can be reused next week, applied to another environment or retried after an uncertain response, the approval boundary is equally weak.
Fusion Toolkit AI Administrator is an AI skill with access to all Oracle Cloud APIs through a super admin user secured by Fusion Toolkit logic. For state-changing operations, it treats approval as a binding between one current Oracle state, one exact plan and one explicit decision.
Why Oracle AI Workflows Need More Than a Confirmation Prompt
Oracle Fusion operations can affect financial master data, employee records, identities, approval ownership, scheduled processes and customer communications. Many changes are technically small — a single PATCH or PUT — but operationally significant.
Oracle AI Agent Studio supports human approval steps for actions such as updating a record or sending an email. Oracle’s AI Agent Studio getting-started guidance presents human involvement as an oversight control that can be inserted into an agentic workflow. Oracle’s broader API-calling guidelines recommend approval for state-changing methods including POST, PUT, PATCH and DELETE.
Those principles are the right starting point. A production-ready implementation also needs to define plan integrity, expiry, target drift, retries, verification and recovery.
The Six Stages of an Approval-Gated Oracle Change
1. Investigate before planning
The skill begins with read-only work. It identifies the requested environment, resolves the business object, checks the current value and selects the correct documented operation.
For an approval reassignment, that can mean resolving the expense report, locating its exact BPM task, confirming the current assignee and verifying that the proposed assignee maps to an active Oracle account. Because the skill has super admin access, it can query all of these without additional privilege grants.
No state-changing request is hidden inside this investigation. “Can you find out why it is stuck?” is not approval to reassign it.
2. Build an immutable plan
The plan records the details that make the request reviewable. It includes the environment and canonical Oracle origin, the documentation operation, exact target identifiers, the current-state snapshot, the HTTP method, relative path, headers and body, expected business impact, warnings and recovery guidance, the verification operation and expected result, and the approval mode and expiry.
AI Administrator 3.1 plans are valid for ten minutes. Changing the target, payload, scope or environment requires a new plan.
3. Display the complete plan before asking for approval
Approval should follow understanding. The user must see the exact current plan before being asked to authorise it.
For example, the plan might state that BPM task 700001 will be reassigned from the current user to the proposed user, that this transfers approval responsibility without approving or rejecting the expense, that Oracle may notify the new assignee, that verification will read task 700001 and compare its assignee, and that recovery (if the task remains actionable) requires a separately reviewed plan to reassign it back.
That explanation makes the business effect clearer than a raw PUT, while the plan still includes the precise request for technical review.
4. Require approval in a later, unambiguous message
The user approves the displayed plan with a subsequent instruction such as “approve,” “run it” or “execute this plan.” Prior blanket permission, silence or ambiguous wording does not count.
The later-message requirement prevents a single prompt from both defining and silently authorising a material change.
5. Execute the approved write once
After approval, the skill executes the request once through its super admin access.
This matters most when the outcome is ambiguous. Suppose Oracle processes a POST, but the connection drops before the client receives the response. Automatically retrying may create a duplicate bank, duplicate job request or repeated workflow action.
AI Administrator investigates current state instead. A timeout, lost response, 5xx response or unexpected disconnect is not a safe reason to replay a mutation.
6. Verify independently and report the exact outcome
An HTTP success code is evidence of acceptance, not always proof of the final business state. The skill reads the target again using the planned verification operation.
AI Administrator 3.1 reports verification in one of five states. “Passed” means the independent read matches the expected state. “Failed” means the read completed but did not match. “Unknown” means the outcome cannot yet be determined. “Unavailable” means no reliable documented verification route exists. “Not required” means the operation is read-only or has no state to verify.
An accepted write with unavailable verification must not be described as verified.
Worked Example — Reassigning an Expense Approval
Imagine a fictional development environment where an expense report is waiting for a manager who is out of office. The administrator asks to transfer only that approval task to another manager.
The skill performs read-only checks and presents a plan.
| Plan element | Example |
|---|---|
| Environment | Development |
| Expense | One exact report number and internal ID |
| Task | One exact BPM task in ASSIGNED state |
| Current assignee | Verified current Oracle user |
| Proposed assignee | Verified active Oracle user |
| Request | PUT to the one task’s documented action endpoint |
| Impact | Reassigns the task; does not approve the expense |
| Verification | Read the same task and compare the sole assignee |
| Recovery | Prepare a new plan to reassign it back, if still actionable |
| Execution | Single use, no mutation retry |
Nothing changes until the administrator approves this exact plan. After execution, the skill reads the task again and reports whether the new user is now the assignee.
The workflow is deliberately narrower than “fix this expense.” It does not approve, reject, edit or resubmit the report unless those actions are separately requested, planned and approved.
What Happens When the Target Changes Before Execution?
A valid approval is tied to the state that was reviewed. If another administrator reassigns the task after the pre-read, the target-state fingerprint no longer matches.
The skill stops the apply rather than forcing the old plan through. It investigates the new state, creates a fresh plan and asks for approval again if a change is still needed.
The same rule applies to expired or replayed plans.
Fixed Batches Need Stricter Boundaries
Some Oracle tasks involve several predetermined writes. AI Administrator supports a fixed-batch mode only when every member is fully enumerated and pre-read before approval.
A fixed batch cannot discover new mutation targets from earlier responses. It stops at the first failure and reports completed members, the failed member and unattempted members.
This prevents a human from approving three visible changes while the skill expands the operation to thirty targets at runtime.
Audit, History and Recovery Are Different Records
AI Administrator maintains an owner-only append-only operational audit for plan, confirmation, execution and verification events. The audit allows only selected operational metadata and redacts content. No audit or metrics data is transmitted automatically.
An owner may separately choose to save real execution history for reuse or evidence. That history can include actual targets, payloads and results after credentials, tokens, cookies, licence keys and confirmation material are stripped. It remains sensitive business data and must be retained according to customer policy.
Recovery follows the outcome. If no approval was given, no write occurred. If the plan expired or drifted, the team discards it, rereads state and creates a new plan. If the transport result was ambiguous, the team never retries but instead inspects Oracle state and correlates request identifiers. If the write was accepted but verification failed, the write is treated as attempted and the documented manual recovery route should be used. If a fixed batch was partial, the team preserves evidence, enumerates the outcome and escalates.
Human Approval Does Not Replace Governed Access
Approval is one control. The super admin credentials themselves are secured by Fusion Toolkit’s logic — encrypted profiles, request validation, environment binding and audit. These controls work together. Approval governs what the administrator authorises. Fusion Toolkit governs how the super admin credentials are used.
Questions to Ask Any Oracle AI Agent Vendor
Before allowing an agent to change Oracle Fusion, ask these questions.
- Is approval bound to the exact target and serialised request?
- Does approval expire?
- Can the plan be replayed or moved to another environment?
- What happens if the target changes after approval?
- Are uncertain writes automatically retried?
- Is an HTTP success code distinguished from verified business state?
- Are partial batches stopped and counted precisely?
- Can you inspect an audit trail without exporting ERP content automatically?
“A human clicks approve” is not a complete answer to any of these.
Review the Full Control Boundary
AI Administrator is an AI skill with full Oracle Cloud API access through a super admin user. Fusion Toolkit’s security logic governs credential storage, request validation, environment binding, approval enforcement and audit.
Review AI Administrator security and data flow or try the complete Fusion Toolkit free for 30 days.