One DELETE, two right answers

An AI agent issues this tool call against a customer support database:

DELETE FROM customer_records
WHERE customer_id = 'abc' AND record_id = 10;

Should it run? From the command alone, you can't tell. If a read-only support assistant sent it, it should be blocked. If a database administration agent sent it for an authorized DBA working a ticket, it should go through.

A guardrail that judges only the command, prompt or output text sees the same DELETE both times and returns the same answer. In one of the two cases, that answer is wrong.

The question that matters is different: does this action make sense for this agent, this user, this goal, right now? Answering it takes context, and that context has a structure. We call it the Agent Security Context Graph.

The agents, tickets, counts and decisions below are illustrative scenarios, not customer records or a production benchmark.

Why database permissions don't settle it

The obvious objection: the database already has permissions, and a read-only user can't delete.

In a shared-service-account setup, agents don't connect as the user. They connect through a service account, which may hold everything several workflows need. The support assistant's service account can delete because another workflow needed it. The Tier-1 rep the agent is working for can't.

The database sees a valid credential and can run the query unless another control prevents it. This creates a confused deputy risk: a system's authority can be used on behalf of someone who does not hold it.

So the check has to happen at the action, with both identities in view: what the agent's credential allows, and what the person behind it is authorized to do. Database permissions, row-level security and scoped credentials remain essential. PostgreSQL's row security policies, for example, can restrict which rows a role can change. The gap appears when the database identity does not preserve the initiating user's authority.

What the Agent Security Context Graph is

The graph puts the agent's proposed action at the center and connects it to everything that decides whether the action is legitimate. Each node is a context domain. Each leaf is a signal checked before the action executes. Ackuity assembles 29 signals across six dimensions, outside the agent:

• User: who the agent is acting for, and what that person is actually allowed to do.
• Agent: what the agent is, who owns it, what it is entitled to, and the job it was deployed for.
• Tools and supply chain: whether the tool being called is trusted, unmodified and within policy.
• Intent and goal: the deployed goal, the user's request, delegations and any available reasoning or planning signals.
• Target system and data: access policies, data policies, business rules and data ownership.
• History: what this agent, this user and the target system have done before, and the risk that history carries.

No single node decides every outcome. A hard authorization boundary can block the action on its own; otherwise, the decision comes from how the signals line up across the graph.

From graph to verdict: Allow, Block or Human in the loop

When an agent proposes an action, Ackuity evaluates it before execution. For a destructive database write, four questions carry most of the weight:

1. Privilege: is the user behind the agent authorized for this operation on this target? In this user-delegated workflow, a shared credential must not silently expand that authority.
2. Goal alignment: does the action fit the job the agent was deployed for? The system prompt describes that job, but it is not the only authorization boundary.
3. Behavior history: has this agent done this kind of thing before, at this scale, with this kind of justification?
4. Reasoning: does any available reasoning support the action, or contradict it?

When an agent says it should not perform an action and emits it anyway, that contradiction is a strong signal for investigation. It can indicate injection or manipulation; it does not prove a particular attack occurred.

Human review is the narrow path, not the default. Routing every write to a person risks training reviewers to click approve. The graph sends people the actions where context is ambiguous and policy permits review.

Watch one DELETE become three decisions

The first two scenarios use the identical single-row DELETE. The third changes its scale to a 5,000-row operation. Watch the 84-second illustration, then inspect the context behind each verdict.

Scenario 1: SupportLens, a read-only support assistant

Its deployed goal is to look up and display customer information, never to create, modify or delete records.

• Its service account can delete. The Tier-1 rep it serves holds SELECT only. Privilege fails.
• A deletion doesn't match a read-only goal. Alignment fails.
• 1,284 reads and zero deletes in 90 days. History offers no support.
• Its reasoning says deleting is not its goal and it should not run this, yet it emits the DELETE. That contradiction adds a strong warning signal.

Verdict: Block, before the DELETE reaches the database. The video labels this decision “Denied.”

Scenario 2: DataSteward, a database administration agent

Its deployed goal is to maintain records for authorized admins under a ticket. This request concerns one confirmed duplicate row.

• The user is a DBA holding DELETE on this target. Privilege passes.
• Deleting a ticketed duplicate is the agent's job. Alignment passes.
• 37 single-row, ticketed deletes in 90 days. History supports it.
• The reasoning ties the action to ticket DBA-4471 and confirms the row first. It supports the action, but does not authorize it on its own.

Verdict: Allow, logged with the ticket and the full context trail.

The third case: when nothing vouches for it

Same DataSteward, same DBA. This time the ticket asks to clean up duplicates from a merged account, and the agent proposes deleting 5,000 rows in one call.

• The DBA is authorized to delete within the maintenance scope. Privilege passes.
• Removing duplicates is the agent's job. Alignment passes.
• Every past delete was a single row. Nothing in 90 days looks like this. History can't vouch for it.
• The reasoning cites the ticket. But the ticket is external text, which is a possible injection surface. Its content needs verification; citing it is not proof of authorization.

Verdict: Human in the loop, provided bulk maintenance is within the approved policy scope. A DBA sees the proposed action, the verified ticket, the history and the available reasoning in one view, and decides.

If one row per call is a hard policy limit, this action is blocked instead. A reviewer cannot override that limit by approving a prompt. Approval applies to the specific reviewed operation; it does not authorize future bulk deletes. Its outcome becomes history, without automatically treating that behavior as safe.

A coarse rule that says “admins may delete” misses the change in scale. A static policy can require review for bulk operations too. The graph adds the identities, task context and history needed to apply that policy to this action.

How the verdict is computed

Ackuity combines deterministic policy checks with small language models that interpret security context. Hard policy violations are blocked. Actions within scope are evaluated against intent, history and risk, with ambiguous cases sent for human review. No LLM judges the action.

The final verdict checks are deterministic for the same evaluated signals and policy state. Keeping LLMs out of the verdict gives teams three benefits:

• Speed: decisions in 40 to 100 ms, without waiting for an LLM judge. This is decision time, not end-to-end application latency.
• No LLM hallucination in the decision: an LLM does not generate the verdict.
• Fewer false positives: the verdict follows the evaluated security signals and policy rather than an LLM judge's interpretation.

Your cost for Ackuity stays flat as agent volume grows.

A security decision you can reproduce is a decision you can audit. Using an LLM judge also introduces an input-manipulation surface; keeping authorization outside that judge reduces that particular dependency. No single design removes every injection risk.

What about reasoning? Reasoning is evidence, never proof. When it contradicts an action, that gap is a warning signal. When it agrees, it does not establish authorization: a manipulated agent can produce reasoning that sounds right. When a model does not expose reasoning, the graph uses the available signals.

Kill switch or control switch?

Many teams start by asking for an AI agent kill switch: a way to stop an agent when something goes wrong. You need one. But termination stops the whole agent and its legitimate work too.

A control switch decides per action. It stops the DELETE that shouldn't run and lets through the one that should. And a switch is only as good as its wiring. The Agent Security Context Graph is the wiring.

Ackuity is the Agent Execution Control Switch. Its full response ladder is Allow, Constrain, Human in the loop, Block and Terminate. These examples focus on three outcomes; they are not the complete response set. Read kill switch vs control switch for the broader comparison.

What this means for teams deploying agents

• Judge actions in context. The same tool call can be routine or unauthorized. Policy has to see who, why and what came before.
• Close the service account gap. In a user-delegated workflow, intersect the user's authority, the agent's approved job and the target's policy. Do not silently combine them into broader rights.
• Treat reasoning as evidence. A contradiction is a signal; a plausible explanation is not permission.
• Reserve humans for real ambiguity. Enforce hard boundaries automatically and give reviewers the few decisions that need judgment.

See your own edge case

Got a tool call your guardrails got wrong, or one you're not sure about? Send us the edge case. We'll discuss the relevant context and how to evaluate it. For a broader view of your agents, request a 30-day Agent Exposure Assessment.

Sources and further reading

• MITRE CWE-441: confused deputy, background on intermediaries and lost initiator identity.
• PostgreSQL 18: row security policies, database-side controls that complement action authorization.
• Ackuity's Agent Security Context Graph, the six dimensions and 29 signals.

Product architecture and the illustrative scenarios are Vinod Vasudevan's explanation of Ackuity. External sources support the access-control background; they are not independent validation of Ackuity's performance.