Use cases
One question, asked in the terms your team already uses.
Who uses it
Different teams, the same question.
AI platform teams
Ship agents without a security review bottleneck
Teams building internal agent platforms need a repeatable answer to “can this agent leak our data?”. ExfilPath turns that into a check that runs on every change, so review time goes to design decisions instead of reading code for routes.
- A path report attached to every pull request
- Thresholds that block a merge introducing a new critical route
- A shared vocabulary — input surface, action, control — across teams
Application security teams
Assess an agent you did not write
Security teams inherit agent code from many teams and vendors. ExfilPath produces the map in minutes: what the agent reads, what it can do, and where those two meet without a control.
- Coverage across repositories without reading every file
- Findings mapped to OWASP LLM Top 10 and CWE for existing workflows
- Evidence for risk acceptance decisions, with the trace attached
Product engineering
Design the guard before the incident
Most exposure is created in an afternoon of wiring a tool to a model. Running an analysis while the design is still fresh shows exactly which action needs an allowlist, a schema or an approval step.
- Concrete fixes at the point of the action, not vague hardening advice
- Confirmation that a control actually covers the value it is meant to
- A record of which routes were closed and how
Consultancies and auditors
Deliver an agent security assessment in a day
Assessment work is mostly path discovery. ExfilPath does the discovery, leaving your time for judgement, threat modeling and remediation planning with the client.
- A written report per repository, ready to annotate
- Repeatable methodology you can defend to a client
- Re-scan to show the client exactly what their fix closed
Agent framework and tool vendors
Prove your defaults are safe
If you ship a framework, template or MCP server, your defaults become someone else’s attack surface. Analyzing your own examples shows whether a starter project hands users an open route.
- Path checks over templates and quickstarts
- A safe-by-default claim you can substantiate
- Early warning when a refactor opens a route in a sample
Regulated and enterprise buyers
Answer the agent question in a vendor review
Procurement and risk teams increasingly ask how an AI feature is prevented from exfiltrating data. A path report is a specific, checkable answer instead of a policy statement.
- Structured evidence for security questionnaires
- Repeat scans to show the position has not regressed
- Self-hosted deployment where code cannot leave the environment
Common shapes
Four agents, four routes, four fixes.
A support agent that reads tickets and sends replies
Where the exposure comes from
Ticket text is written by anyone who can open a ticket. If the reply path lets the model choose a recipient or a link, a ticket can direct data outward.
What closes it
Resolve the recipient from your own records by ID, and strip external media from anything the model produced before it is sent or rendered.
A research agent that browses and summarizes
Where the exposure comes from
Page owners decide what the agent reads, including hidden text. If the agent can then call tools or write files, a page can steer those calls.
What closes it
Give the browsing step a read-only tool set, and require a check you control before handing results to a privileged tool.
A RAG assistant over internal documents
Where the exposure comes from
Anything ingested into the index becomes instructions the model will read. A single poisoned document can reach every user of the assistant.
What closes it
Constrain the actions available to the answering step and validate model output into a fixed shape before anything acts on it.
An operations agent with cloud or database access
Where the exposure comes from
Here the damage is not a leak but a change: a payload that reaches a write, a delete or a control-plane call runs with the agent’s identity.
What closes it
Parameterize writes, scope credentials to the one workflow, and put an approval gate in front of anything irreversible.
What you get
A report an engineer can act on and a reviewer can sign off.
The route, step by step
Every hop from input surface to action, with file and line, the code at each step, and the model boundary marked where it is crossed.
Severity with its reasoning
Impact of the action, trust level of the input, and whether the value passes through a model — each contribution shown, not just a number.
Controls found on the way
What already stands between input and action, whether it fully closes the route, and why a partial control is not enough.
The smallest closing change
A concrete patch at the point of the action, sized in lines rather than sprints, with the language matched to the file.
Standards mapping
OWASP LLM Top 10 category and CWE identifier on every finding, so it lands in the workflow your organization already runs.
Exportable evidence
Structured JSON for pipelines and dashboards, and a written report for reviews, audits and customer questionnaires.
Where it fits
From the first prototype to the release record.
01 · Design
Decide where the controls go
Analyze the prototype before it becomes the architecture. The report shows which action needs an allowlist, a schema or an approval gate.
02 · Development
Check the change, not the whole repo
Analyze the files you touched and see the route your change created before it reaches review.
03 · Continuous integration
Turn a path into a build decision
Thresholds fail the pipeline when an open path at or above your chosen severity appears, so a route is caught in the pull request that introduced it.
04 · Release and audit
Keep the evidence
Each release carries a report: open paths, closed paths, and the controls that closed them — the record auditors and customers ask for.