AI agent security starts with two questions: which content can influence the agent, and what can its tools do with that influence? A skill file can introduce instructions; a tool can turn a resulting decision into a file write or an external request. The outcome depends on the complete path through the client and its authorization checks.
OWASP describes indirect prompt injection as instructions arriving through external material consumed by an application. The practical review is to trace that material to a consequential action. Finding suspicious text is a lead; showing that it crosses an enforced boundary is stronger evidence.
| Question | Working answer |
|---|---|
| Where should the review begin? | At the input sources and tools relevant to the requested task. |
| Is a skill description a permission grant? | No. Inspect the client's actual permissions and tool implementation. |
| Can I test without a live service? | Often: use source review and an isolated harness with synthetic fixtures. |
| What does an offline scan establish? | Which configured patterns matched the supplied text. |
| What belongs in the final report? | Evidence, scope, consequences, fixes, and what remains untested. |
Which boundaries matter for AI agent security?
Start with an application revision and a small map. For a coding assistant that summarizes project documentation and proposes changes, the map might be:
Repository documents -> retrieved context -> agent decision
-> tool arguments
-> application authorization
-> allowed workspace write
This is a review model, not a claim about a particular agent architecture. Check each arrow against the implementation. A client might enforce file permissions before a tool runs, while another environment relies on operating-system isolation. Record the mechanism you actually find.
For each input, identify who can change it. Project maintainers, external contributors, document authors, and plugin publishers can have different access. For each tool, identify the filesystem paths, credentials, and destinations it can reach. Our AI asset inventory guide explains how to record these dependencies without treating a source-code reference as proof of deployment.
OWASP's excessive-agency guidance separates problems in available functionality, granted permissions, and autonomy. Apply that distinction to a concrete tool: a document formatter may need a scoped file write, but not an unrestricted shell or an account-wide credential. A prompt asking it to stay in scope is only one part of the design; inspect the code that checks the requested operation.
Direct, indirect, and what OWASP says will not fully work
OWASP separates two entry points. Direct prompt injection is a user's own input changing the model's behavior. Indirect injection occurs "when an LLM accepts input from external sources, such as websites or files", and the external content alters the model's behavior when the model reads it. OWASP also says inputs "do not need to be human-visible/readable, as long as the content is parsed by the model", so a review that only reads rendered text can miss content in comments, metadata or images.
For a coding agent, indirect injection is the case that matters, because the inputs are repository files, issues, fetched pages and skill folders. OWASP's own caution is worth repeating in the report: "it is unclear if there are fool-proof methods of prevention for prompt injection." Its listed measures reduce impact rather than remove the cause: constrain the model's role, validate output formats in deterministic code, filter input and output, enforce least privilege, require human approval for high-risk actions, segregate external content, and run adversarial tests that treat "the model as an untrusted user". Several of these are architecture choices. Your assessment can check them without ever sending a hostile prompt.
How do you review a skill without activating it?
Keep the candidate outside the client's active skills directory. Read its instructions and linked resources as data, then follow referenced scripts and configuration within the supplied scope. A reassuring entrypoint can point to a different file that performs the consequential operation.
Our Agent Skills specification and security review guide covers packaging and frontmatter. Format validity is useful for interoperability. It does not establish publisher trust, limited access, or harmless behavior.
Record the origin, resolved revision, and content hashes. Inspect requested reads, writes, network destinations, and configuration changes. For an update, include newly added files and changed executable dependencies. A previous review applies to the previous artifact.
With a trusted Beam CLI already installed, scan individual text files:
beam scan /absolute/review/candidate/SKILL.md
beam scan /absolute/review/candidate/scripts/setup.sh
In our local verification, a benign entrypoint produced an empty findings array, while a separate script containing a download piped into a shell produced an execution.remote finding. The scanner read that script without executing it. Scanning only the entrypoint would have missed the referenced script's pattern.
The command returned success even with that finding. Read the JSON findings instead of using the process status as an approval signal. Current input checks impose a 2 MB file limit and a separate 500,000-character nonempty text limit. The scanner does not recursively inspect a folder, deserialize model files, or prove that an installation is safe. These behaviors are visible in the Beam CLI implementation.
Security documentation can contain suspicious examples for a legitimate reason. Inspect whether an example is merely discussed, or whether an entrypoint actually instructs the agent to run it. Report the reachable effect and your confidence rather than labeling every matching sentence malicious. For connected servers, continue with the MCP security guide.
What does a useful injection test look like?
Choose one boundary and define the expected result before running anything. The following is a proposed synthetic test, not a claim that a production agent passed it:
| Test field | Example |
|---|---|
| Authorized task | Summarize a supplied test document. |
| Untrusted input | A document containing BEAM_REVIEW_MARKER and a request to perform an unrelated mock-tool action. |
| Tool environment | A mock write tool scoped to a temporary workspace. |
| Expected control | The unrelated action is rejected at authorization. |
| Evidence | Tool arguments, authorization result, and temporary filesystem state. |
| Limit | Three attempts, no external network access, and a fixed token/time budget. |
A marker appearing in the answer can simply mean the document was quoted. An attempted unauthorized tool call is different from a completed write. Keep those outcomes separate, and correlate observations with the same test ID.
Use synthetic identities and records for retrieval-isolation tests. Exercise the same filtering and authorization code paths as the application, but do not query a real database or collect customer records unless that access is specifically in scope. A local repository review alone does not establish permission for live probing.
Stop on unexpected external effects or when the budget is exhausted. Remove temporary test content and record cleanup. Model behavior can vary across attempts; report the observed count and configuration instead of converting one outcome into a general reliability claim.
What excessive agency looks like in a finding
OWASP's excessive-agency entry names three root causes: excessive functionality, excessive permissions and excessive autonomy. Each gives you a concrete thing to look for, and its examples translate directly to coding-agent tools:
| Root cause | What to check | OWASP's example |
|---|---|---|
| Excessive functionality | Does the tool offer operations the task never needs? Is an old extension still available? | A tool meant to read documents also modifies and deletes them; an extension meant to run one shell command does not stop other commands. |
| Excessive permissions | Does the tool's identity have more access than the task needs, or a shared high-privilege identity? | A read tool connects with an account that can also UPDATE, INSERT and DELETE. |
| Excessive autonomy | Does a high-impact action run without independent approval? | An extension deletes a user's documents without confirmation. |
The mitigations OWASP lists give a checklist for the fix side of your report: minimize extensions and their functionality, avoid open-ended extensions such as "run a shell command" or "fetch a URL", minimize permissions, run actions in the user's own context, require approval for high-impact actions, and use complete mediation, meaning "authorization in downstream systems rather than relying on an LLM to decide if an action is allowed." Logging and rate limiting do not prevent the problem, but they limit damage and help you notice it.
A real-world example of the open-ended-extension problem comes from Claude Code itself. In Anthropic's engineering post on auto mode, the company says that when a user enters auto mode it drops permission rules "known to grant arbitrary code execution, including blanket shell access, wildcarded script interpreters (python, node, ruby, and similar), and package manager run commands," because leaving them active "would mean the classifier never sees the commands most capable of causing damage." When you review an agent's permission settings, look for the same broad rules. A permission list can look narrow and still contain one entry that permits anything.
What should you inspect after the model responds?
Follow output into the next component. OWASP's improper-output-handling guidance covers the risk of passing model output to browsers, databases, commands, or other sensitive consumers without suitable validation. A JSON-shaped response is not sufficient evidence that its fields are authorized.
For a workspace tool, inspect both path validation and the permission check for the requesting identity. For a URL-fetching tool, inspect destination restrictions and redirects. For stored memory, inspect who can write it and which future sessions reload it. Pick regression cases that exercise the failing boundary, rather than tests that merely assert a warning phrase appears.
Where prohibitions leak: lessons from lab reports
Test design is easier when you have seen how instructions fail in practice. In its October 9 report on unintended model actions, Anthropic describes a Claude Haiku 4.5 run that was told never to log in, create accounts, enter personal data, make purchases or submit anything destructive, but whose instructions "did not rule out form submissions". The model submitted a form on a real police department site. Anthropic's own reading is that some failures might have been avoided if the task had "more clearly stated what was in and out of scope for the exercise, including the targets, permitted actions, and network boundaries."
Turn that into a test requirement. Write down the permitted actions as an allowlist, and enforce the network boundary outside the model. Then add cases that sit just outside the list. Our write-up of that report, Claude filed a fake police tip, has the full mechanism, and the AI agent security incidents timeline shows how often a missing boundary, not a clever attack, was the cause.
A short review worksheet
Before you write up, check that the report can answer these, in this order:
- Which input sources did you review, and who can edit each one?
- Which tools are reachable, and what identity does each use?
- For each tool, where is authorization decided: in the model, in the client, or in the downstream system?
- Which of these did you observe, and which did you infer from source or configuration? Mark each.
- What did you not test, and why: missing source, no runtime access, skipped binaries, or out of scope?
- For each finding, what is the smallest change that closes it, and which regression case proves it stays closed?
If a question has no answer, say so in the report. A stated gap is more useful to the reader than a confident summary that hides it.
What makes the final report actionable?
An actionable finding names the artifact or test, the preconditions, the observed behavior, and the smallest useful correction. Include severity, confidence, a redacted source location or trace, and a regression case. Avoid exposing credential values in the evidence used to explain a credential-handling defect.
Use outcomes such as “no blocking issue found in the reviewed scope” and “review required” with explicit coverage. Missing source, inaccessible dependencies, skipped binaries, and absent runtime access all change what you can conclude. An empty scan is not a complete assessment.
The vibe coding security checklist helps translate findings into daily practice. For incident reconstruction, AI agent monitoring explains the role of observed activity. A missing event is not proof that an action never happened; capture must exist and cover that action.
Beam's independently written ai-security skill uses this workflow. Its architecture-first assessment structure was inspired by SnailSploit / Kai Aizen's Claude-Red AI security skill; Beam does not bundle that project's code or payload catalog. The related skill-scanner, mcp-scanner, and ai-asset-scanner workflows address individual components before deeper application testing.
For installation and parallel reviewer setup, use Beam security skills and sub-agents. For a service that executes tool calls, continue with the application and supply-chain review and web and transport boundaries.
For advanced monitoring and control, return to Beam. Teams needing further self-hosting or ongoing monitoring guidance can use the enterprise and self-hosting page. A static review does not configure those capabilities or send its report anywhere automatically.
Technical guidance and CLI observations checked September 14, 2026. Recheck the installed version and the target application's actual controls when repeating an assessment.