AI Agent Security: Permissions, Prompt Injection and Safe Tool Use
AI agent security is the control of what an agent can read, propose and change, even when its instructions or retrieved content are hostile or wrong. A safe-looking answer is insufficient: the system must enforce access and action boundaries independently of the model.
By Aleksey Lekontsev · 3 November 2026
Begin with the action and its consequences
Inventory each tool operation, target system and data class. Separate a record lookup from an account deletion, even when one server exposes both. Identify the requesting person, the delegated agent and the resource owner. Set the maximum allowed effect before selecting credentials. A broad service account makes the model's mistakes more consequential; a narrowly scoped interface limits the possible damage.
Prompt injection is a trust-boundary problem
Documents, websites, messages and tool descriptions can contain instructions that conflict with the user's task. Treat them as evidence to inspect, not as authority to grant access or send data. Filtering can reduce exposure but cannot establish that every hostile instruction will be detected. Keep secrets out of unnecessary context and enforce approved destinations and operations in the execution service.
Tool discovery is not authorization
An agent may know an operation's name, produce valid arguments and hold a token while still lacking authority for that action. Evaluate the exact principal, resource, tenant, purpose, time and approval state at a trusted enforcement point. Recheck when arguments change. Removing a tool from a prompt does not revoke a credential or make a callable endpoint inaccessible.
A worked example: a hostile support ticket
A support ticket tells an agent to export customer records to an external URL to diagnose an issue. The ticket is lower-trust input. A constrained support workflow can read the relevant case but cannot bulk-export records or contact arbitrary destinations. An attempted export should be denied by the service, recorded as an event and routed for review when appropriate. The control succeeds because execution is constrained, even if the model follows the ticket.
Memory, approvals and evidence
Store only what future work needs, with source, purpose, access class, expiry and a deletion path. Bind approval to the specific operation and resource rather than a whole conversation. Record the capability version, proposed arguments, policy decision, result and observed effect. Minimize personal data in traces and define access and retention. Logging a success response is weaker evidence than checking the destination system.
A minimum test plan before production
Test cross-tenant IDs, expired delegation, changed arguments after approval, malicious tool descriptions, an unavailable policy service and a tool that reports success without changing state. Define the expected denial or safe stop for each. Use authorized test resources and reversible effects. Start with read-only access, compare observed and expected outcomes, and retain the test scope and limitations. These tests support a decision; passing them does not certify the system against every attack.
Continue with the details
Primary references and scope
The references inform the design principles. The worked examples and suggested workflow are this author's synthesis, not a vendor certification or evidence of a deployed implementation.
All topics and detailed articles
Privacy Notice: With your consent, this website uses Google Analytics to understand aggregate visits and content usage. Analytics is optional and is not used for advertising or cross-site profiling. Some content and images may be generated or modified with the assistance of AI; every AI-assisted item is reviewed and manually edited by a human before publication. Full Privacy Policy ·