Before Your AI Agent Acts, Add a Policy Checkpoint

AI agents can reason. The danger starts when we let them carry that reasoning straight into a live system.

An agent reads a customer email, decides a refund is justified and updates the finance system. It sees a sales opportunity, chooses a discount and sends the quotation. It notices a stock shortage, creates a purchase order and commits the company to spend.

Each decision may sound reasonable. That does not mean the agent has the authority to carry it out.

Rocket Software recently announced an expansion of its EVA platform for mainframe operations. One part caught my attention: a security layer called PlanGuard that places a policy checkpoint between AI reasoning and system execution. The company describes scoped identity controls, policy decisions, activity logs and human oversight for governed actions.[1]

I have not used this product. I am interested in the operating pattern, not reviewing the product.

For any agent connected to an ERP, CRM, finance platform or service desk, the safer sequence is:

Reasoning → policy checkpoint → execution → audit

That checkpoint is where business authority becomes explicit.

Reasoning is not permission

An agent may correctly conclude that an invoice is overdue. That gives it a reason to act, not permission to take every available action.

It might be allowed to:

• read the invoice and payment history;
• recommend the next follow-up;
• draft an email;
• update an internal status field.

It may still need approval to:

• send the email;
• suspend the customer account;
• waive a fee;
• change a credit limit;
• reverse a payment.

Many agent deployments blur these actions together. The team connects the agent to a system, grants broad access and relies on a prompt that says “ask before doing anything important.”

That is not an operating control. “Important” is not a permission level, and a prompt is not the final enforcement point.

The control should sit after the agent proposes an action and before the connected system executes it.

Build the permission map around verbs

Most access-control discussions start with applications: access to CRM, access to ERP, access to email.

That is too broad for digital coworkers. Start with verbs.

1. Read

The agent can retrieve information but cannot change it.

Examples:

• read a customer’s order history;
• check whether an invoice is overdue;
• retrieve an approved product price;
• inspect a service ticket and related knowledge articles.

Read access still needs boundaries. A sales agent may need customer and pipeline data but not payroll records. A service agent may need warranty information but not every finance field.

2. Recommend

The agent can propose the next action, but a person decides.

Examples:

• recommend a credit-control follow-up;
• flag a likely duplicate supplier invoice;
• suggest the right service priority;
• propose a stock reorder quantity.

This is often the right starting point for a new workflow. The agent contributes speed and attention while the domain expert checks whether its judgment matches the business.

3. Write

The agent can change a record inside an approved scope.

Examples:

• add a call summary to the CRM;
• classify a support request;
• populate a draft purchase requisition;
• update a delivery-status field from verified source data.

Writing creates operational consequences even when no money moves. The checkpoint should validate the target record, allowed fields, source evidence and whether the change conflicts with a locked or approved state.

4. Transact

The agent can trigger an external or financial action.

Examples:

• send a quotation;
• place an order;
• issue a refund;
• submit a payment;
• confirm a booking.

This is where many workflows should require a human approval step, at least until the business has enough evidence to define safe limits. A $20 refund and a $20,000 refund should not share the same rule.

5. Approve

Approval is a separate authority, not a more powerful version of writing.

An agent that prepares a payment should not automatically approve it. An agent that creates a supplier should not also release the first transaction. An agent that proposes a discount should not be the only control on margin.

The old maker-checker principle still works. AI changes who performs the work, not why separation of duties exists.

6. Reverse

Before granting execution authority, decide whether the action can be undone.

A CRM note can be corrected. A draft order can be cancelled. A payment sent to the wrong account may not be recoverable.

Reversibility should affect the approval threshold. The harder an action is to reverse, the stronger the checkpoint should be.

Give every agent a scoped identity

Do not let several agents operate through one shared administrator account.

Each digital coworker should have its own identity, job scope and accountable human owner. Its permissions should reflect the workflow it performs, not the maximum access the integration technically supports.

This creates a cleaner audit trail:

• which agent proposed the action;
• what information it used;
• which rule allowed or blocked execution;
• who approved an exception;
• what changed in the business system;
• whether the action succeeded or was reversed.

Without that trail, the team cannot investigate mistakes or improve the workflow. It can only inspect the final record and guess how it got there.

Human-in-the-loop must name the loop

“Human oversight” is too vague to design a reliable process.

Name the exact approval point.

For example:

• The agent may draft quotations, but a sales manager approves discounts above the standard band.
• The agent may prepare supplier payments, but finance approves the batch before release.
• The agent may classify and route support tickets, but a service lead approves account credits.
• The agent may update CRM records from verified meeting notes, but cannot delete records or change contractual terms.

The human is not watching every step. The human is making the decisions that carry financial, legal, customer or reputational consequences.

That is orchestration. Let digital coworkers execute the repeatable work. Keep authority where judgment and accountability belong.

A practical starting exercise

Take one workflow you want an agent to perform and create a simple table with five columns:

1. Proposed action
2. Business system
3. Permission level
4. Approval condition
5. Reversal method

List every action using a verb. Do not write “manage invoices.” Write “read invoice,” “match purchase order,” “flag exception,” “draft follow-up,” “send follow-up,” “apply credit” and “reverse credit.”

The detail will expose where your actual controls are missing.

Better models will make agents more capable. That does not remove the need to define authority. It makes the boundary more important because the agent can reach a decision and act faster.

Before you connect another agent to a business system, add the checkpoint. Require every proposed action to pass the policy check before the system carries it out.

Sources

[1] https://markets.businessinsider.com/news/stocks/rocket-software-advances-governed-agentic-ai-on-the-mainframe-with-rocket-eva-1036567250 — Rocket Software Advances Governed, Agentic AI on the Mainframe with Rocket EVA