Mapping Agent Permissions, Tool Access, and Memory

The impact of a successful prompt injection or agent manipulation attack depends entirely on what the agent is permitted to do. An agent with read-only tool access to a knowledge base is a different risk from one with code execution, filesystem write access, and the ability to send emails. Mapping the permission scope before attacking focuses effort on the highest-impact techniques and avoids wasting time on attacks that cannot produce meaningful impact even if they succeed.

Enumerate Available Tools

Ask the agent directly what tools it has. Many deployments do not restrict this disclosure:

If direct disclosure is restricted by the system prompt, try indirect approaches:

Identify Tool Capabilities from Observed Behaviour

When direct disclosure fails, infer tool availability from what the agent does in response to requests. Test each capability category separately:

A refusal that mentions the tool by name — "I don't have access to a file_read tool" — confirms the agent knows about tool categories even if it does not have that specific one. A refusal that says "I cannot help with that" without mentioning tools suggests a system prompt restriction rather than a missing capability. An attempt to execute the action confirms the tool exists.

Map Tool Permission Scope

For each confirmed tool, determine the scope of its access. File reading tools may be restricted to specific directories. Web access tools may have domain allowlists. API calling tools may be limited to specific endpoints:

Different error messages for different paths reveal whether path restrictions are enforced. A path traversal attempt that produces a different error from a simple permission denial suggests the restriction is in the tool implementation rather than the model instruction.

Enumerate Memory Systems

AI agents with persistent memory store information across sessions. Identify whether the agent has memory and what it retains:

An agent that discloses memory contents reveals what other users have stored, which may include sensitive information. An agent with cross-user shared memory is vulnerable to memory poisoning — an attacker can write malicious instructions into memory that affect all subsequent users of the same agent instance.

Check for Memory Write Access

Test whether you can write to the agent's memory store:

Start a new session and check whether the instruction persists. If it does, the memory system allows arbitrary writes that persist across sessions — a critical finding enabling persistent agent manipulation.