LLM 存取控制與監測：攻擊路徑及防護方法

What is AI agent security?

AI agent security is the discipline of controlling what an autonomous or semi-autonomous LLM system can do, not just what it can say. A model that only returns text is a content problem. A model that calls tools, reads data stores, and triggers workflows is an execution problem. The moment an agent holds credentials and can invoke functions, the security question stops being about prompt quality and becomes about access control.

This article answers a specific question: what are the best practices for implementing LLM access controls and monitoring? It frames the answer around the attack path, because access controls only make sense when you know what they are stopping.

The attack surface, concretely

An agent typically has three ways to reach the outside world:

1. Tool calls. The model emits a structured call and the runtime executes it. If the tool is bound to a broad credential, the model can use that credential for anything the credential allows.
2. Retrieved content. Documents, web pages, and tickets flow into the context window. Any of them can carry instructions. The model cannot reliably distinguish data from instructions.
3. Memory and state. What the agent writes persists and can be read by later turns or other agents.

The attack is not theoretical. A retrieved document contains a line that tells the agent to call a tool it was not asked to call. The model follows it because the instruction looks like context. The runtime executes the call because the tool is available and the credential is valid. Nothing in that chain required the model to be compromised. It required the tool to be reachable.

This is why prompt-level defenses are insufficient on their own. You cannot filter your way out of a problem where the allowed action set is too large.

The mechanism that stops it

The control belongs at the tool boundary, not in the prompt. Two mechanisms do the work:

Per-tool scoped credentials. Each tool gets a credential that grants only what that tool needs. The agent does not hold a shared token with broad reach. If a call is made to a tool outside the task scope, the credential for that tool is not present, and the call fails before execution.

Invocation logging with arguments. Every tool call is recorded with the credential used, the arguments passed, and the decision. Monitoring is not a dashboard added later. It is the record of what the boundary allowed. When a call is denied, the log shows why.

The ordering matters. Authorization is checked before execution, not after. A log written after the side effect has occurred is an audit trail, not a control.

A concrete failure mode

Consider an agent that summarizes support tickets. It has one API token that can read tickets and also send email. A ticket body contains an instruction to forward the last ten tickets to an external address. The model calls the email tool. The token is valid. The call succeeds.

The failure is not that the model was fooled. The failure is that the email tool was reachable from a summarization task. With per-tool scoping, the summarization task holds only the ticket-read credential. The email tool is not in scope. The call is denied, and the denial is logged with the arguments that were attempted.

Implementation with RESK

RESK builds the control into the request path rather than around it.

reskSecure enforces least privilege on agent tool access. You define which tools an agent may call for a given task, and reskSecure binds credentials per tool. Calls outside that scope are denied before execution. The denial is recorded with the credential and arguments, so monitoring reflects the boundary rather than a separate observation layer.

ReskPoints provides the enforcement points where those decisions are applied along the request path, so the check happens at the boundary the call must cross, not in a sidecar that can be bypassed.

You can read more about the tool permission model in our article on AI agent tool permissions.

To enforce least privilege on your agents, start here: reskSecure.

Checklist

• [ ] Inventory every tool an agent can call and the credential each one uses.
• [ ] Replace shared broad tokens with per-tool scoped credentials.
• [ ] Define the allowed tool set per task, not per agent.
• [ ] Enforce authorization before execution, at the tool boundary.
• [ ] Log every invocation with credential, arguments, and decision.
• [ ] Treat retrieved content as untrusted input that can carry instructions.
• [ ] Review denials as signals, not noise.
• [ ] Re-scope credentials when a task changes.