AI agents do more than generate text. They select tools, access data, update records, trigger workflows, and act on behalf of people.

That changes what “safe” means.

Traditional LLM guardrails typically inspect prompts and responses. They can detect unsafe content, prompt injection patterns, sensitive data, or malformed output. Those controls remain useful. But they do not answer the operational question that matters most:

Is this agent authorized to take this specific action, in this specific context, right now?

A safe-looking prompt can still produce an unsafe tool call. A valid API credential can still authorize too much. A complete log can still document an action that should never have executed.

This is where AI agent security requires a separate control layer: one that maps an agent’s action surface, evaluates each action at runtime, and authorizes the action before execution.

Below are seven common mistakes and the practical controls that fix them.

---

1. Treating the system prompt as a security boundary

The mistake

You tell the agent:

• Never approve your own purchase order.
• Do not access customer records without permission.
• Ask for approval before deleting data.
• Only use tools for the current task.

Then you assume those instructions enforce the boundary.

They do not.

A prompt is an instruction to a probabilistic system. It is not an authorization mechanism. Prompt injection, poisoned context, conflicting instructions, or a model error can cause the agent to disregard the intended behavior.

The fix

Move critical controls outside the agent’s reasoning loop.

Use prompts to describe intent. Use policies and infrastructure to enforce limits.

For every material action, the control layer should evaluate:

1. Identity : which agent is acting, and on whose behalf?
2. Scope : which tool, operation, data, or system can it reach?
3. Policy : is this action allowed, blocked, or subject to approval?

The agent should not decide whether its own action is acceptable. An external runtime authorization layer must make that decision.

The control: prompts guide behavior; policy enforcement controls behavior.

---

2. Guarding text while ignoring actions

The mistake

You deploy an LLM firewall or content filter that scans inputs and outputs. It flags jailbreaks, toxic content, PII, or suspicious instructions.

You now have visibility into the conversation. You do not necessarily have control over the workflow.

An agent can receive a harmless prompt and still:

• Issue a refund.
• Change a production configuration.
• Send an external email.
• Delete a record.
• Export sensitive data.
• Approve a transaction it initiated.

The text may pass every content check. The action may still violate business policy.

The fix

Add action-level guardrails after the agent selects an operation but before the tool executes.

This creates a clear division:

Control type	Governs	When it acts	What it produces
LLM guardrails	Prompts and responses	Around the model call	Flag, redact, or refuse
Tool validation	Arguments and schemas	Before the tool receives data	Accept or reject the request
Runtime authorization	Business action and context	Before execution	ALLOW, BLOCK, or ESCALATE

The distinction matters. Content safety is not action authorization.

LangGuard’s AI governance platform places deterministic enforcement at the action layer. Arbiter evaluates the planned tool call against identity, scope, policy, and context before the downstream system receives it.

Not a signal. A decision.

---

3. Giving agents broad permissions “for flexibility”

The mistake

You connect an agent to a system and grant a wide permission set because the workflow is still changing.

The agent can read and write when it only needs to read. It can access every customer when it only needs one account. It can call multiple finance operations through a single shared credential.

This creates excessive agency. If the agent makes an error or accepts poisoned context, the blast radius is already large.

Connection-level access is not operation-level authorization.

The fix

Apply least privilege at the agent and operation level.

A practical permission model should answer:

• Which tools can this agent call?
• Which operations can it perform on each tool?
• Which records, fields, or systems can it access?
• Which actions require a named human?
• Which actions are never available to the agent?

Start with read-only access. Add narrowly defined write permissions for specific workflows. Separate approval from preparation. An agent that creates a purchase order should not automatically approve it.

At design time, SCOPE-MCP maps the complete action surface:

• Connected tools.
• Exposed operations.
• Reachable systems of record.
• Data and workflow dependencies.
• Segregation of Duties (SoD) conflicts.
• Regulatory and internal-control classifications.

This turns least privilege from a security intention into a written, reviewable scope.

A broad connection is not a narrow authorization.

---

4. Validating the request but not the context

The mistake

You validate that a tool call matches its technical schema:

customer_id: string
refund_amount: number
reason: string

That is necessary. It is not sufficient.

A correctly formatted request can still be wrong. The customer may not exist. The requesting user may not own the account. The amount may exceed the workflow limit. The agent may be attempting to refund an order that another agent already processed.

Schema validation checks whether the request is shaped correctly. It does not determine whether the request is authorized.

The fix

Validate three things before execution:

1. Structure : are the tool arguments valid?
2. Context : do the entities, relationships, and workflow state make sense?
3. Authority : does this agent have permission to perform this operation now?

For high-impact workflows, evaluate the requested value, frequency, destination, and history. A single low-value refund may be allowed. A series of refunds that crosses a threshold may require escalation.

The runtime must evaluate the actual action, not only the text that led to it.

Valid input does not prove valid authority.

---

5. Relying on deployment-time permissions instead of runtime authorization

The mistake

You review the agent during deployment and approve its tool access. After that, the agent operates under the same permissions regardless of the task, user, data, or current conditions.

That approach assumes the action is known in advance. It is not.

Agents decide what to do while they run. Their actions depend on the prompt, retrieved data, tool results, model output, and current workflow state. A design-time review can describe what the agent could do. It cannot authorize what the agent is about to do.

The fix

Use both design-time mapping and runtime authorization.

Stage	Question	Required control
Design time	What can the agent reach?	Map and classify the action surface
Runtime	Is this action allowed now?	Evaluate identity, scope, context, and policy
Continuous	Can we prove what happened?	Record the decision and approval chain

LangGuard uses SCOPE-MCP for design-time discovery and classification. Arbiter then evaluates each action before the tool call executes.

Safe actions proceed automatically. Exceptional actions are blocked or routed to an approver.

Design time defines the boundary. Runtime enforces it.

---

6. Treating human approval as a process document

The mistake

Your policy says, “A manager should review payments above $10,000.”

But the agent can still submit the payment directly. The review exists in a document, a ticket, or an informal operating procedure. It does not exist in the execution path.

That is not human-in-the-loop governance. It is post-action review.

The fix

Embed approval gates into the runtime.

When an action crosses a defined threshold, the system should:

1. Hold the action before execution.
2. Show the approver the agent, user, tool, operation, parameters, and policy trigger.
3. Route the request to a named person.
4. Record the approval or denial with a timestamp.
5. Resume execution only after approval.

Use approval gates for actions such as:

• Financial transactions.
• Production changes.
• Data deletion.
• External communications.
• Access to regulated systems.
• SoD conflicts.
• High-blast-radius operations.

The agent should not be able to bypass the gate by changing its wording or selecting a different tool. The policy must govern the operation and the destination.

Human review after execution is not authorization.

---

7. Logging activity without producing evidence

The mistake

You collect application logs, model traces, API events, and security alerts. When something goes wrong, you search across them to reconstruct what happened.

A log line tells you that a call occurred. It does not necessarily tell you:

• Which agent acted.
• Which person authorized the workflow.
• Which policy applied.
• What scope the agent had at the time.
• Whether a human approved the action.
• Why the system allowed or denied it.

During an audit or incident, reconstruction creates uncertainty. Uncertainty creates delay.

The fix

Record the authorization decision as evidence at the moment it occurs.

A replay-ready record should connect:

• Agent identity.
• Delegating human or workflow identity.
• Tool and operation.
• Parameters and target system.
• Applicable policy.
• Authorized scope.
• Decision: ALLOW, BLOCK, or ESCALATE.
• Named approver, if applicable.
• Decision and execution timestamps.
• Relevant upstream model, gateway, and runtime path.

This evidence supports security investigations, internal controls, and frameworks such as the NIST AI Risk Management Framework and the current OWASP GenAI LLM Top 10.

Monitoring remains important. It identifies anomalies, failures, and policy trends. But monitoring alone does not stop an unauthorized action.

Not a reconstruction. Evidence.

---

The practical guardrail architecture

A production-grade approach uses three layers:

1. Map

Discover every agent, tool, operation, data source, and system of record. Classify the action surface against internal policies, SoD rules, and regulatory obligations.

2. Enforce

Evaluate every material action after the agent reasons and before the tool call executes. Automatically allow safe actions. Block violations. Escalate exceptional actions to named approvers.

3. Record

Capture the action, identity, policy, decision, approval, and timestamps in a tamper-evident, replay-ready ledger.

This is the difference between an agent that is merely observable and an agent that is governed.

Are your guardrails ready for production?

Ask your team these seven questions:

1. Can a prompt override a critical control?
2. Do your guardrails govern tool calls, or only text?
3. Can you list every operation each agent can perform?
4. Does the system authorize each action at runtime?
5. Can an agent access an operation simply because it shares a connection?
6. Does a high-risk action pause before execution?
7. Can you prove who authorized each action and which policy applied?

If the answer to any question is unclear, your deployment has a control gap.

LLM guardrails remain one part of a secure architecture. They screen content. They do not replace action authorization.

For enterprise AI agents, the required sequence is clear:

Map the scope. Authorize the action. Record the evidence.

That is how AI agent security becomes enforceable governance rather than a collection of warnings and after-the-fact alerts.

Explore LangGuard or schedule a focused assessment for one priority agent or workflow.