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.
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 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.
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.