When Your AI Agent Becomes a Skeleton Key
The agent is a process running with the full permissions of every tool you connected, steered by the most untrusted input we have ever accepted.
Connect an agent to your CRM, your email, your files, your database, and it inherits everything those tools can do. It calls them on your behalf. It uses your credentials.
There is no permission layer between the AI and the tool.
In ordinary software, layers sit between a user and an action. Authentication, authorization, role-based access, input validation. Every layer is there because we learned that user input cannot be trusted.
AI agents skip most of it. The agent is not a user. It is a process running with the full permissions of every tool you connected. The input driving it is natural language, which is the most untrusted input we have ever built systems to accept.
So when someone tricks the AI, through prompt injection, a poisoned document, an email it summarizes, a support ticket it reads, they are operating your tools with your credentials. The model is the steering wheel.
The blast radius is every tool the agent can call.
Why the model is not a security boundary
The model parses intent and calls tools. That is the job. It is not checking what is safe. It is not enforcing your business rules. It is not validating that the person asking to “send invoices to procurement” is the same person whose email it is signed into.
The boundary has to live somewhere else: in the infrastructure between the model and the tools.
I keep saying the same sentence, including on About, because it is the rule this company is built under:
Your model is not a security boundary.
Teams treat agents like a chat box with plugins. They are closer to giving a stranger root access to half the company and hoping they behave.
What sits between the model and the tools
Permission layers. Tool allowlists that validate parameters. Sandboxed execution for anything touching code or files. Audit logs the agent cannot quietly rewrite.
Most teams have a model, a list of tools, and a plan to add those later. Later is the day the agent already had standing access to CRM, email, and the database.
On this company the boundary is the control plane. Nothing sends, spends, deploys, or merges until a gate that has actually been seen to fire says it may. The public ledger of that work is the machine.
How to answer “what can it do if someone tricks it?”
One question for anyone shipping AI into production systems:
What can your agent actually do if someone tricks it?
Name the tools, the parameters, the data sources, the side effects. Thirty seconds. If you cannot, you have a hope.
The human half of the same problem is an approval that always says yes, and a dashboard that has never gone red. I wrote the failure list in What Breaks First When the Machine Runs Operations, and the green-dashboard case in A Monitor That Has Never Gone Red Is Not a Monitor.
Questions
Is the LLM a security boundary for an AI agent?
The model parses intent and calls tools. That is the job. Policy, allowlists, sandboxes, and audit logs have to live in the infrastructure between the model and those tools, because the model is not checking what is safe.
What is a skeleton-key agent?
An agent connected to CRM, email, files, and a database that inherits everything those tools can do. There is no permission layer between the model and the tool, so a trick against the model operates your credentials.
How does prompt injection turn into a tool action?
The input is natural language from tickets, documents, and mail. Once that text is in the same context as the tools, a hidden instruction can steer a call. The model is the steering wheel. The blast radius is every connected tool.
What should sit between the model and CRM, email, or a database?
A permission layer that validates parameters, an allowlist of tools, sandboxed execution for anything that touches code or files, and an audit log the agent cannot rewrite. On this company those gates also cover send, spend, deploy, and merge.
How do I know the blast radius of my agent?
Name the tools, the parameters, the data sources, and the side effects, in thirty seconds. If you cannot, you do not have a security model. You have a hope that the model will behave.
Also in this argument
- The machine — the public ledger of gates, receipts, and what actually ran.
- What Breaks First When the Machine Runs Operations — The first failures are owner failures: a decision the agent never reads, an alarm that has never gone red, and an approval that became a rubber stamp.
- A Monitor That Has Never Gone Red Is Not a Monitor — A green agent dashboard is an untested claim. Silence has two explanations you cannot tell apart from the outside.
