Expertise / 04
AI & supply-chain security
Examine what your agents can act on, what your build trusts, and how untrusted input can reach a privileged action.
Check the client, server and upstream system as separate principals.
Original Web3Sec diagram. On small screens, scroll the figure or open the full-size version.
Who this is for
A clear question.
A useful outcome.
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.
What you should leave with
- 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.
Review boundary
What the work can cover.
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.
From context to evidence
How the engagement works.
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.
Concrete outputs
Deliverables you can use.
Examples below are illustrative. They describe possible work products, not past client findings or promised results.
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.
Scope and responsibility
Boundaries worth agreeing early.
- 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.
Before sharing code, customer information, or incident artifacts, agree on confidentiality and a private transfer channel. Keep the initial message high level.
Before we begin
Common 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.
Go a little deeper
Practical reading.
Connected work
Related services.
Web & API pentesting
Follow the attack paths between identities, application workflows, APIs, and the systems they can reach.
Explore this service →03Incident readiness & response
Prepare the decisions, access, and evidence your team will need when normal assumptions stop holding.
Explore this service →06Security strategy & technical GTM
Connect security priorities, product decisions, and a technical story that stands up to scrutiny.
Explore this service →