The Credentials Checked Out. The Action Was Still Wrong.

Part 1 of Where agent access stops being enough, a five-part series on what can go wrong after an AI agent connects, and what it takes to control it.

A support agent has access to the billing system because its job includes refunds. A customer asks for $40 back on a late delivery. The agent issues $4,000.

Or it refunds the right amount to the wrong account. Or, while it is in there, it pulls the payment history of every customer who shares the requester's last name.

Every call authenticated. Every token was issued by your identity provider. Every request passed the API gateway. None of it was what the business asked the agent to do.

This is the first place agent access stops being enough: valid access, wrong action.

Access answers a different question

Identity and access management answers one question well: can this agent connect to this system? Keep investing in it. Agents need identities, credentials, and scopes as much as people do.

In practice, though, access is often granted in broad strokes: billing write, CRM read, mail send. Those grants were sized for people and services whose range of actions was known in advance. A person's job defines what they do with refund rights, and a service runs the same code paths every time.

An agent chooses among actions at runtime, based on its instructions, the content it retrieves, and its own reasoning. The same grant now covers far more possible actions, and nobody chose them ahead of time. The question that matters moves from "can it connect?" to "is this specific action right for the task it was given, on behalf of the person it acts for?"

A broad billing-write permission, by itself, doesn't distinguish $40 from $4,000, or one ticket's customer from the whole table. Fine-grained rules at the gateway or the API can close part of that gap, but they rarely know which task the agent is on or whom it is acting for.

Why the usual answers fall short

Narrower scopes. Do it anyway. But an agent that issues refunds needs refund permission, and a static scope granted ahead of time can't say "this customer, this amount, for this ticket."

Rules in the system prompt. The agent is asked to follow them. It can misread them, be steered by content it retrieved, or simply get it wrong. A rule only the agent enforces is guidance, with no independent check behind it.

Logging and monitoring. You need the record. But a log records the event; it doesn't prevent it. By the time an alert fires, the money may have moved.

What has to decide instead

The decision has to happen at the moment of action, outside the model, and it has to weigh what the action is for:

• The task. The goal the run was started with and what the agent says it is doing now, checked against each other. The agent's own description is input to the decision, never the authority for it. An agent resolving a delivery complaint has no reason to read payroll.
• On whose behalf. The agent acts for someone, and its authority comes from that person and that task. Holding a right yourself doesn't mean every agent you start should exercise it.
• The specifics. The amount, the record, the destination. Refunds within a limit go through. Anything above it is refused.
• A deterministic answer. The same identity, task context, action details, and policy version produce the same decision, with no model in the decision path.

This is the core of Agent Runtime Governance: authorize the action, every time, before it runs.

How Watchlight AI Beacon handles it

Beacon evaluates each governed action before it executes: the agent's identity, the authority delegated to it and by whom, its declared intent, what the run has already done, and your policy, which can read the details of the action, such as the amount.

The declared intent is bounded. It has to fit the goal the run was started under and the scope the delegating person granted. An action outside them is denied however the agent describes it.

You can also require a person's approval for categories of action, such as financial operations. The action is refused until someone approves it, and that approval covers that one action, once.

If the action fits, it proceeds. If it doesn't, it is denied before it runs, at the enforcement points you deploy inside the agent's framework and on the network. Either way, the decision is recorded: who authorized the action, which policy decided it, and what happened.

You can watch this in one of our demos. An HR assistant acts for an administrator who is allowed to export the entire employee table. Working on a question about one employee, the agent reads that one record. When it tries the bulk export, Beacon denies it, even though the person it acts for holds that right. The person may. The agent, on this task, may not.

Five questions to ask about your own agents

1. Which of your agents can take an action whose wrong version costs money or exposes data?
2. For each one, what decides whether a specific action fits the task: the agent itself, or something outside it?
3. Can that decision see the amount, the record, and the person the agent acts for?
4. When the action is wrong, does it stop before it runs, or do you find out from a log?
5. Could you show an auditor who authorized it?

If the answer is the agent itself, its prompt and its own reasoning are all that stand between it and the wrong action. Without an independent, task-aware check before execution, nothing reliably stops that action before it runs.

Next in the series

Valid access, wrong action is one agent making one bad call. Part 2 looks at what happens when that agent hands work to other agents, and authority quietly widens at every handoff.

Come see it for yourself. Request a demo and watch Beacon allow the right action and deny the wrong one, with valid credentials on both. Or start a production-readiness pilot on the workflow you are most worried about.