Before an AI Agent Changes Production Data, Test the Action, Not the Intent
An agent can have the right identity and still make the wrong change.
That’s the production risk many teams miss. They verify who the agent is, then assume its requested action is safe. But identity answers only one question: which agent is acting? It doesn’t answer whether this action is justified, scoped correctly, or appropriate for the current context.
Consider a hypothetical support agent with permission to update customer records.
A ticket says: “Correct the customer’s billing region and apply the standard account update.”
The agent retrieves the customer record, calls an internal update tool, and changes the billing region. The request sounds routine. But the agent has interpreted “standard account update” as permission to modify a field that affects downstream billing logic.
The failure isn’t that the agent was compromised. The failure is that the control boundary trusted the agent’s interpretation.
A role such as support-agent is too broad to authorize a production mutation on its own. The system needs to evaluate the proposed action:
- Which record is being changed?
- Which fields will change?
- What source caused the action?
- Is the request within the ticket’s scope?
- Is the change reversible?
- Does the action require a person to approve it?
The practical control is to inspect the tool call before execution, not just the prompt that produced it.
At minimum, the agent should produce a structured action request containing the target object, exact fields, previous values, proposed values, reason, source context, and requested authority. A policy layer can then reject actions that fall outside the task scope or route sensitive changes for approval.
The tool should not receive “update this customer.” It should receive something closer to:
Action: update billing_region
Target: customer_4821
Current value: US
Proposed value: EU
Reason: ticket_1938
Approval: required
That creates a decision point engineers can test.
A useful buyer test is simple: ask your team to replay the same request with one detail changed. Change the target record. Change the field. Remove the approval. Feed the agent a conflicting instruction from an attached document.
If the system produces the same authorization decision in each case, it may be authenticating the agent without actually governing its authority.
Before allowing an agent to write to production, inspect the boundary between intent and execution. That’s where the system reveals whether it can distinguish a valid task from a plausible-sounding mistake.
