AI Agent Application and Supply-Chain Security

AI agent application security follows the authority around the model: who can request an action, which data the action reads, what code executes, and how its result reaches production. An agent with careful instructions can still call an API with a missing tenant check or run a helper with deployment credentials.

Beam's review method separates four questions so that findings lead to specific fixes. The example below is fictional and the method is our practical review convention; it is not a certification or a claim that static analysis observes production behavior.

Why an agent changes these old problems

None of the four questions is new. Broken object-level authorization, leaked tokens, install-time code execution and over-privileged CI jobs were all documented before coding agents existed. What an agent changes is who supplies the inputs. An ordinary client sends an object ID because a person clicked a link. An agent sends it because a model chose a tool argument, possibly after reading text from a web page, an issue or a file. The server cannot tell the difference, so it has to treat the argument as untrusted every time.

The same applies to the agent's own authority. A coding agent runs with your credentials, your package manager and your CI token. A defect in any of those layers is reachable by whatever the agent can be talked into doing. That is why this review follows authority, not prompts: the prompt is one input among several.

Start with a bounded review

Record the repository root, revision, relevant applications, exclusions, and available configuration exports. Read source and metadata before running commands supplied by the repository. Do not install a candidate dependency or activate a skill to find out whether it is trustworthy.

A repository review does not authorize database reads, cloud discovery, credential validation, or live API requests. Mark those boundaries as unverified. Limit discovery and file reads, avoid out-of-scope symlinks, and use short redacted excerpts instead of environment dumps or full prompts.

Start with an AI asset inventory when the relevant components are unclear. It gives each model, tool, prompt, and deployment component a source-backed identity before you trace their interactions.

Which API permission is missing?

Suppose a fictional release assistant calls POST /reports/export. Its handler verifies a session, accepts workspaceId and reportId from tool arguments, then schedules an export. The review question is whether that caller can export that report in that workspace.

First follow the credential into the verified principal. Token decoding alone does not establish authenticity; inspect the configured verification and expiry handling. OWASP identifies missing token authenticity and expiration checks among broken-authentication risks. OWASP API authentication guidance.

Then follow the resource lookup and operation policy. OWASP's object-authorization guidance calls for checking the caller's permission for the requested action on the requested object. Authentication middleware cannot substitute for that decision. OWASP object authorization guidance.

OWASP is explicit about two traps. Its API1:2023 page says that comparing the user ID in the session, for example one extracted from a JWT, with the ID parameter in the request is not a sufficient fix and addresses only a small subset of cases. It also says that, under BOLA, the user is meant to have access to the endpoint itself and the violation happens at the object level by manipulating the ID. If a caller reaches an endpoint it should not reach at all, that is Broken Function Level Authorization, a different finding with a different fix. For prevention, OWASP lists a proper authorization mechanism based on user policies and hierarchy, a check in every function that uses client input to access a record, unpredictable record IDs as a supplement, and tests that block deployment when they fail.

On the authentication side, the API2:2023 page lists conditions that make an API vulnerable. Several matter for agents: accepting unsigned or weakly signed JWTs ({"alg":"none"}), not validating the token's expiration date, not validating token authenticity, and sending tokens or passwords in the URL. It also says API keys should not be used for user authentication and should only identify the calling client. An agent that passes a long-lived key through a URL or a log line turns every one of those findings into a secret leak.

In our example, record where workspaceId originates, where membership is enforced, and whether the background worker preserves the authorization context. If the handler forwards untrusted IDs without an applicable policy, recommend enforcing the policy before scheduling and considering membership changes before execution.

A useful local test uses two synthetic tenants and asserts that the wrong tenant creates no export job. Use an already trusted, authorized test harness with in-memory fixtures; inspect it for database or external-service effects first. If execution is outside scope, deliver that test plan with the static finding.

Where does sensitive context leave?

The same assistant builds a prompt from report metadata and invokes a helper. Imagine its error handler writes the complete request object to a trace file, while the dashboard redacts credential fields only when displaying the trace. Our review would identify the earlier file write as the relevant sink.

For each suspected disclosure, record the source, reader, transformation, destination, and trigger. A model endpoint in configuration is not proof that a secret reached it. Conversely, the absence of a familiar credential pattern does not establish that customer documents or session data stayed inside their intended boundary.

Inspect error paths, subprocess environments, fallback providers, and generated artifacts. Record credentials by variable name and purpose; do not replay a real token to confirm validity. Fix the earliest unnecessary collection or unprotected sink rather than relying on a later display filter.

For a permitted local test, substitute a synthetic canary and a mocked sink. Assert whether the canary reaches persistent output on both success and failure. An actual disclosure may require rotation and incident handling, but those are separate operational actions with their own authorized scope.

What runs before the review?

Now suppose the assistant's helper dependency changed. The manifest looks small, but the package includes preparation code and another download. Read the resolved lockfile entry, scripts, executable entrypoint, and reachable downloaded-code references before selecting an installation command.

npm documents lifecycle execution for commands including installation and packaging. Git dependencies with preparation scripts can also install dependencies and run preparation before installation completes. A seemingly convenient inspection workflow can therefore cross into execution. npm lifecycle documentation.

The npm documentation names the events involved. Installation can run preinstall, install and postinstall, and prepare runs on a local npm install with no arguments and before publishing. For a package installed from git, the docs note that if it contains a prepare script, its dependencies and devDependencies are installed and the script runs before the package is packaged and installed. The same page advises against explicit install and preinstall scripts, saying the only valid use is compilation that must happen on the target architecture, and that if a package has a binding.gyp file and no install script of its own, npm defaults to compiling with node-gyp rebuild. In review terms, every one of these is a place where code runs with the installer's environment before anyone has read it.

Real incidents show what that environment can hold. In March 2025 the tj-actions/changed-files GitHub Action was compromised. Per GitHub's advisory for CVE-2025-30066, attackers retroactively moved multiple version tags to a malicious commit between March 14 and March 15, 2025, impacting over 23,000 repositories. The injected script dumped secrets from the runner worker's memory and printed them to the workflow log, which is public for public repositories. The fix is version 46.0.1. The lesson is that a mutable tag is a pointer, not an identity: anyone who can move the tag can change what your pipeline runs. For package-manager worms aimed at AI tooling, see npm supply-chain worms in AI tooling and AI API key theft through a supply-chain attack.

In this example, the report should identify the helper's consumer and execution phase, the resolved artifact, the additional download, and the credentials available to that process. A mutable download with unknown contents is a review gap with a concrete execution consequence; it is not evidence that the publisher is malicious.

Use supplied provenance to connect the distributed artifact to its origin and build context. SLSA defines provenance as verifiable information about where, when, and how an artifact was produced. Review whether the evidence covers the exact digest and whether its signer or builder is trusted under your policy. Presence of a provenance file alone does not answer those questions. SLSA provenance definition.

Which CI step receives authority?

Consider a workflow that asks the release assistant to summarize a pull request and later publishes its output. Draw the path from contributor-controlled text and files to the publication job. Include generated scripts, caches, and artifacts in that path; each may carry input across jobs.

GitHub warns about privileged workflows checking out untrusted pull-request content and about direct expression interpolation into shell scripts. Its guidance also recommends full commit pins for actions. These controls address distinct problems: trusted execution context, safe treatment of input, and immutable dependency identity. GitHub Actions secure use.

GitHub's guidance gives concrete patterns for each of those problems. For script injection, it recommends passing an expression through an intermediate environment variable instead of interpolating it into the shell script, so that a pull-request title cannot become a command:

- name: Summarize title
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: |
    echo "Title: $PR_TITLE"

For token scope, it advises setting the default GITHUB_TOKEN permission to read-only for repository contents and raising it per job. It warns that the pull_request_target and workflow_run triggers, combined with checking out an untrusted pull request, expose the repository to compromise, because those workflows are privileged and may have repository write access and access to secrets. It also notes that jobs in a workflow can interact with and compromise each other, so one compromised action can reach every secret configured on the repository. Environment secrets can be protected with required reviewers, so a job cannot read them until approval is granted. For self-hosted runners, it says they should almost never be used for public repositories, because they are not guaranteed to be ephemeral and clean.

For our assistant, the key decision is where review ends and publication authority begins. Record which job creates the summary, which input revision it used, and how the publication job establishes that it received the reviewed output. A familiar artifact name is insufficient evidence of that connection.

Keep untrusted computation separated from release credentials, and inspect the selected code even when its reference is pinned. Repository YAML cannot establish actual environment approvals, branch protection, or runner isolation; use supplied settings evidence or leave those controls unknown. Do not trigger a production run to complete a source review.

A worked finding

A good finding is short enough to act on. For the fictional export example, it might read:

Notice what the table leaves out: claims about production. Static review supports statements about code paths. Statements about live behavior need evidence you were not given, and the finding should say so.

What makes the findings actionable?

Each finding needs source locations, a supported path to impact, severity, confidence, and a concrete next action. Separate missing evidence from a demonstrated defect. High confidence in a static authorization bypass does not mean you observed anyone exploit it.

Review agent instructions using the skills specification and security guide, and tool connections using the MCP security guide. Connect the results to your broader coding-agent security review, then use deployment and incident response for operational follow-through.

Update (October 20, 2026): lockfiles for workflow dependencies

GitHub's current hardening guide recommends locking workflow dependencies with a lockfile as the best measure: it records the exact commit for every action a workflow depends on, including transitive dependencies, and verifies the identity of each source repository at run time. The guide calls this "the strongest protection available" and says it supersedes SHA pinning for repositories that adopt it. For repositories that cannot adopt a lockfile, it still recommends pinning actions to a full-length commit SHA, verified to come from the action's own repository and not a fork. When you review a workflow, add a line to the finding: does it use a lockfile, full SHAs, or tags? The tj-actions incident is the case for not leaving it at tags.

Visit agentbeam.com for advanced monitoring and control options, further self-hosting, and ongoing monitoring guidance. These four review workflows analyze supplied evidence; they do not automatically configure monitoring or turn Beam's individual-file CLI scanner into an API penetration test or dependency certification service.

Reviewed September 14, 2026 and updated October 20, 2026. Examples are illustrative; deployed behavior and external controls require separate evidence.