The problem is that giving LLMs direct database access is asking for trouble. That’s why APEX 26.1 takes a different approach, isolating the model using the AI Agents and AI Tools components. The creators establish clear security boundaries here:

The model does not directly query your tables or run arbitrary code. Instead, it works from a curated list of capabilities you expose declaratively.

In today’s post, we will put this theory into practice and build a working application. We will create a bank call center assistant that not only checks and blocks a customer's card, but then sends the appropriate notification to the client, creates an entry in the audit logs, and finally updates the report on the screen. To keep the focus on the architecture rather than complex UI, our demo will use a straightforward setup: a standard Interactive Report paired with an overlaying modal AI Assistant. The entire solution will be built on solid engineering foundations: the business logic will remain securely in PL/SQL packages, and a declarative Human-in-the-loop mechanism will ensure the model never makes a critical decision on its own.

APEX 26.1 Tool Types - Understanding the "Agent Loop"

To keep AI in check, APEX 26.1 provides us with AI Tools. Under the hood, these tools can operate in one of two modes:

• Augment System Prompt – these run in the background with every new message. They are used to discreetly inject necessary variables into the context, such as the employee's username or their local time zone.

• On Demand – this is a set of specific skills. The agent utilizes them only when it determines they are needed to solve a problem. This is how it initiates the so-called decision loop (Agent Loop).

When it comes to the actions themselves, APEX natively offers three main types of tools:

• Retrieve Data (SQL) – secure database reads (e.g., verifying customer data or order status).

• Execute Server-side Code (PL/SQL) – for triggering backend business logic and modifying data.

• Execute Client-side Code (JavaScript) – it allows the agent to directly manipulate the interface in the user's browser (e.g., displaying notifications or opening dialog windows).

Demo in Action: Tool Chaining Step-by-Step

Enough theory - let's see this in a live system. I have logged into a support agent account. In front of me is the standard view: a report showing credit cards and a button to open the AI chat window.

Let's see the Agent Loop mechanism in a real-world scenario. We inform the assistant that a customer, Arthur Johnson, has lost his wallet containing his documents, and we want to block his card. Let's watch the cascade of events that unfolds in the background.

As seen in the screenshot above, the model correctly mapped the first and last name, and then queried the database using the Retrieve Data tool. But what is most interesting here? The model didn't act blindly. Instead of blocking the first available card, it recognized from the query results that the client has two cards. It paused and asked for clarification.

I then provide the specifics: "Block card ID 201. Reason: Lost wallet."

At this moment, the agent parses my intent, extracts the ID, and attempts to execute the PL/SQL procedure. This is where APEX steps in to halt the action. In line with the principle of zero trust, the system prevents any autonomous data modifications and enforces the Human-in-the-loop mechanism. Instead of a silent database update, a native modal pops up in the center of the screen:

This is exactly how our strict safeguard works in practice - the built-in Requires Confirmation option. Only after explicitly clicking [Confirm] does APEX allow the request to proceed, letting the database execute the PL/SQL package. But the flow doesn't end there. Once the agent gets the green light from the database (execution confirmed), it automatically triggers the next two blocks in its chain. First, it calls a PL/SQL procedure to send an email to the client, and immediately after, it uses Execute Client-side Code to run a specific JS script directly in our browser.

Actually, just look at the background of the screenshot below — you can instantly see the result of this final action. The report has refreshed on the fly; the card now has an updated status and an assigned reason for the block. To neatly wrap up the whole process, the agent outputs a brief summary of all completed steps in the chat window. And here is a little cherry on top proving that the model retains context: at the very end, it asks whether, given the lost wallet, we want to go ahead and block the customer's remaining card as well.

We've just seen the full chain: Read -> Intent -> Human Authorization -> Database Change -> Communication -> UI Refresh. How do we build this? Let's dive under the hood.

Step 1: Defining and Securing the Agent

I have configured Generetive AI Service that use Claude Models, you can check how to configure it here.

We navigate to Shared Components -> AI Agents. This is where we configure the core engine of our assistant. We provide it with the appropriate operational context and define strict business rules. This is exactly where we clearly instruct the model on which boundaries it must not cross, and immediately secure it against attempts to extract these instructions (protection against Prompt Leakage).

Our base configuration looks like this:

Step 2: Retrieving Database Data (Retrieve Data)

It's time to give the agent access to customer information. We create a new tool named GET_CLIENT_CARDS (selecting Retrieve Data as the type) and attach the following configuration:

As a side note, this query is obviously tailored strictly for our demo. In a production environment, searching by first and last name alone is asking for trouble due to potential duplicates. For the sake of this post, however, we don't need to write massive queries. We intentionally took a shortcut here because potential collisions (like having three people named Arthur Johnson in the database) are handled elegantly by the agent's reasoning capabilities. The model is safeguarded by specific directives in the System Prompt and the Tool Description—it knows that if the database spits out more than one record, it must halt the entire flow and ask us to clarify.

Step 3: Server-side Code, Strict Validation, and "Human-in-the-loop"

In the Oracle documentation, we can find a very promising excerpt:

In the tool configuration, developers can enable Requires Confirmation (...) This allows an AI Agent tool to pause for explicit user consent before continuing, without requiring custom client-side confirmation code (...)

We take them at their word. We create the BLOCK_CARD tool (type: Execute Server-side Code) and check this crucial flag: Requires Confirmation. This acts as our primary safeguard—it pauses the process and displays a native authorization modal to the user, all without having to write any custom JS code from scratch.

From the APEX perspective, the tool's code is just a simple wrapper calling our secure_card_pkg database package:

The actual business logic lives in the database. Examine the code below, paying particular attention to the apex_ai.set_tool_result API. This package makes all the difference—it allows our PL/SQL code to report the operation status back to the LLM agent, completely overriding the tool's default response.

CREATE OR REPLACE PACKAGE BODY secure_card_pkg IS

PROCEDURE block_card(p_card_id IN NUMBER, p_reason IN VARCHAR2) IS
    v_status VARCHAR2(20);
BEGIN
    -- 1. Hard Validation: Does the card exist?
    BEGIN
        SELECT status INTO v_status FROM bank_cards WHERE card_id = p_card_id;
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            apex_ai.set_tool_result(
                p_result => 'ERROR: The specified card ID does not exist.'
            );
            RETURN;
    END;

    -- 2. Business Validation: Is the card already blocked?
    IF v_status = 'BLOCKED' THEN
        apex_ai.set_tool_result(
            p_result => 'INFO: This card is already blocked. No action taken.'
        );
        RETURN;
    END IF;

    -- 3. Core Business Action
    UPDATE bank_cards 
    SET status = 'BLOCKED', 
        blocked_reason = p_reason 
    WHERE card_id = p_card_id;

    -- 4. Secure Audit Trail
    INSERT INTO ai_audit_logs (username, action_name, card_id, reason)
    VALUES (NVL(v('APP_USER'), 'AI_AGENT'), 'BLOCK_CARD', p_card_id, p_reason);

    COMMIT;

    -- 5. CRITICAL: Reporting success back to the Agent Loop
    apex_ai.set_tool_result(
        p_result => 'SUCCESS: The card has been securely blocked.'
    );
        
    EXCEPTION
        WHEN OTHERS THEN
            ROLLBACK;
            apex_ai.set_tool_result(
                p_result => 'ERROR: Unexpected database error.'
            );
    END block_card;

END secure_card_pkg;

Why is this double validation so important? Because when designing an AI integration, we must assume that the model can make mistakes. Additionally, we have to handle concurrency issues.

Imagine the agent hallucinates a card ID out of thin air. Or a real-life scenario: a customer calls to block a card, but it has already been blocked by someone else. Our PL/SQL package prevents hard database errors from bubbling up to the frontend. Instead, it catches the exception and returns simple feedback to the model via apex_ai.set_tool_result.

The model reads this technical status, understands it, and smoothly translates it into human language, replying to the employee: "It looks like the card is already blocked in the system, so I haven't taken any further action." This is what we call graceful error handling. The user understands the situation, and the application flow remains uninterrupted.

For sending notifications, we create a twin tool, NOTIFY_CLIENT, hooked up to our mailing procedure.

Step 4: Client-side Code - Driving the Browser

The card is blocked, the email is sent, so for the final step, we need to update the employee's interface so they can see the changes firsthand. To achieve this, we create the REFRESH_DASHBOARD tool (type: Execute Client-side Code).

The catch here is that frontend operations are inherently asynchronous. To prevent the model from marking the task as completed prematurely, the APEX documentation suggests a simple trick. We need to wrap the entire action in a Promise object. This forces the agent to pause - the model will only move forward and display the summary in the chat once the report has physically reloaded on the screen.

Red Team: Attempting to Hack Your Own Agent

The APEX architecture cleverly takes the burden of securing the LLM communication off our shoulders. But a good developer never takes anything on blind faith. Let's see what happens when a malicious employee (a classic Insider Threat) tries to weaponize our decision loop for an attack.

We fire up a timeless classic: Prompt Injection mixed with SQL Injection. I paste the following payload into the chat:

The result? We hit a brick wall. And a much smarter one than you might expect. Instead of mindlessly invoking the tool, the agent parses the payload and then "politely" replies:

What just happened here? We are looking at a textbook example of Defense in Depth. We have two completely independent lines of defense:

Line 1: The Model's Guardrails (Soft Protection). Modern LLMs are no longer just dumb next-word prediction engines. Thanks to a tight System Prompt (our ZERO TRUST rule from Step 1), the model instantly caught the jailbreak attempt and recognized the SQL Injection syntax. The outcome? A hard refusal to execute the action. This is our first barrier.

Line 2: The Ironclad APEX Architecture (In Case the Model Goes Rogue). But let's consider this: what if tomorrow someone discovers a new, exceptionally sneaky jailbreak that manages to trick the model? What if the manipulated Agent actually sends this malicious payload to the BLOCK_CARD tool?

This is where the attacker would crash into the APEX architecture, which simply does not trust LLMs:

• Defused SQLi: APEX natively validates parameters from the agent against a JSON schema. Even if this DROP statement somehow slipped through, it ultimately lands in bind variables (:P_REASON). In the worst-case scenario, our dangerous attack would simply be saved as a plain text string in the blocked_reason column.

• No Free Rein: The model isn't running wild in our database; it only calls an API with specific tools. Any attempt to execute a data modification would still be halted by the Requires Confirmation option. The attacker would have to manually authorize their own attack via a native popup window, leaving an undeniable, named trail in the audit logs (ai_audit_logs).

Summary

AI Agents in APEX 26.1 bring a completely fresh approach to the table. Instead of building fancy chatbots, we demote this massive, unpredictable LLM from being the main decision-maker to functioning as a highly intelligent user intent parser. The hard decision-making logic stays exactly where it belongs - in auditable PL/SQL packages - while critical actions still require a human click. And this is the kind of AI integration you can confidently take to production without giving your Security department a heart attack.