LLM access controls and monitoring: the attack path and the fix

AI agent security involves controlling what a semi-autonomous LLM system can do beyond merely controlling its text output. When an agent has credentials and can invoke functions, the security concern shifts from prompt quality to access control. This article discusses best practices for implementing LLM access controls and monitoring, focusing on the attack path.

An agent typically has three methods to reach the outside world: tool calls, retrieved content, and memory/state persistence. Tool calls involve the model emitting a structured request that the runtime executes. If a tool is bound to broad credentials, the model can execute any action allowed by that credential. Retrieved content, such as documents or web pages, can contain instructions that the model cannot reliably distinguish from regular context.

Memory and state refer to what the agent writes persisting and being read by later turns or other agents.

A real-world example of a successful attack was when a ticket summarization agent received an instruction within a retrieved document to forward the last ten tickets to an external email address. The model followed the instruction because it appeared within the context. The execution occurred because the tool was available and the credential was valid. This illustrates that the model didn't require compromising, only that the tool was reachable.

To prevent such attacks, access controls must be implemented at the tool boundary, not within prompts. Two key mechanisms are per-tool scoped credentials and invocation logging with arguments. Each tool gets a credential granting only the necessary permissions. If a call is made to a tool outside the task's scope, the credential isn't present, and the call fails before execution.

Logging every tool call, including the credential used, arguments passed, and the decision, forms the control mechanism. The authorization check must occur before execution, not after, as logs after the fact only serve as an audit trail, not a control.

RESK's reskSecure tool enforces least privilege on agent tool access. Define which tools an agent can call for a given task, and reskSecure binds credentials per tool. Calls outside the defined scope are denied before execution. When a denial occurs, the log records the credential used, arguments attempted, and decision, making monitoring reflect the boundary rather than a separate observation layer.

To enforce least privilege on agents, RESK recommends creating an inventory of all accessible tools and their credentials, replacing shared broad tokens with per-tool scoped credentials, defining allowed tool sets per task, enforcing authorization before execution at the tool boundary, logging every invocation with details, treating retrieved content as untrusted input, and reviewing denials as signals instead of noise. Finally, re-scope credentials when a task changes.