# AI & supply-chain security

Canonical: https://www.web3sec.news/services/ai-supply-chain-security
Provider: Raiders (https://www.web3sec.news/about)

Examine what your agents can act on, what your build trusts, and how untrusted input can reach a privileged action.

## Who this is for

Teams adding agents or retrieval to a product, allowing AI tools to change systems, or relying on complex package and CI/CD workflows.

An agent becomes a security concern when its interpretation of text can cause an action: reading a private document, calling a tool, sending a message, changing source, or deploying code. A build has a related problem when untrusted contributions or mutable dependencies can influence a privileged job. The review follows those paths end to end. Model behavior is part of the analysis, but enforceable controls belong at tool, identity, data, approval, and deployment boundaries.

### Diagram: A tool connection crosses several trust boundaries.

Check the client, server and upstream system as separate principals.

![An MCP client sends a scoped tool request to an authenticated server, which calls an upstream system with its own authorization. Returned data travels back as untrusted evidence. Connecting a server does not give returned content authority over future actions.](https://www.web3sec.news/diagrams/mcp-trust.svg)

[Full-size SVG](https://www.web3sec.news/diagrams/mcp-trust.svg) · [PNG download](https://www.web3sec.news/diagrams/mcp-trust.png)

Original explanatory control model; not a reconstruction of private incident evidence.

## Outcomes

- Understand which untrusted inputs can influence sensitive reads, writes, external requests, and production changes.
- Reduce excessive authority in tools, CI jobs, dependencies, and credentials while retaining the product workflows the team needs.
- Create testable security properties that remain meaningful when model output, package content, or external documents change.

## Scope

- Agent authority: tool schemas, identity propagation, tenant context, credential scope, approval steps, output handling, and the ability to combine individually permitted actions.
- Prompt injection and retrieval boundaries: web pages, repository files, tickets, documents, tool responses, memory, and indirect instructions encountered during normal tasks.
- Data movement: private context supplied to models or tools, outbound destinations, log retention, rendered output, and paths that could expose information to a different user or external service.
- Supply-chain trust: lockfiles, install scripts, package provenance, mutable action references, pull-request workflows, release tokens, artifact promotion, and production deployment permissions.

## Process

### Map inputs and authority

Provide architecture and data-flow diagrams, sample tasks, tool definitions, relevant code and workflows, approved test identities, model/provider configuration, and deployment context. Identify the highest-consequence actions and the controls expected to constrain them.

### Test abuse cases at the boundary

Construct controlled scenarios where retrieved content or external input attempts to redirect behavior. Observe whether authorization, destination restrictions, tenant isolation, and approval checks still hold. Inspect build paths for untrusted code reaching secrets or write permissions.

### Harden and validate

Prioritize controls that can be enforced independently of a prompt: least privilege, structured tools, scoped credentials, destination policies, explicit confirmation for consequential actions, and isolated execution. Record concrete regression scenarios and retest the agreed changes.

## Illustrative deliverables

These describe possible work products, not past client findings or promised outcomes.

### Trust-boundary and authority map

An inventory of identities, data classes, tools, and allowed actions. Illustrative example: a support agent can read one tenant’s tickets but cannot export all tenant records or invoke a deployment tool.

### Abuse-case evidence

Reproducible scenarios, observed control behavior, and recommendations. Illustrative example: an external document asks an agent to send private context to an unrelated endpoint, and the review evaluates whether the tool layer blocks the request.

### Hardening and regression plan

Prioritized permission and workflow changes with acceptance criteria. Illustrative example: a pull-request job loses release credentials and publishes only an unprivileged artifact for a separately authorized promotion job.

## Boundaries

- Testing uses agreed accounts, datasets, repositories, tools, and environments. Production actions, real data exfiltration, and access to unrelated organizations are excluded.
- A review cannot guarantee that a model will never follow an unwanted instruction. The focus is limiting consequences through controls that can be inspected and tested.
- Training-data assurance, foundation-model red teaming, privacy/legal assessments, and enterprise-wide vendor certification require separately defined expertise and scope.

## Questions

### Is a stronger system prompt enough?

A prompt can explain intended behavior, but sensitive permissions should be enforced outside the model. The review checks whether the tool or service independently authorizes the requested action and the specific data it touches.

### Does this include traditional dependencies and CI?

Yes, when included in scope. Agent integrations often inherit repository, package, and deployment trust problems, so reviewing the adjacent build and release paths can be more useful than testing prompts in isolation.

### How do you evaluate a control?

Define an allowed task and a prohibited consequence, then exercise the boundary with representative adversarial inputs. Record the environment and observed result, and retain a regression scenario for subsequent changes.

[Discuss this work](https://www.web3sec.news/contact) · [Approach](https://www.web3sec.news/approach)