What’s Your Agent Actually Doing? Mapping the Security Surface of Agentic Systems
There are three questions most security reviewers ask in the first ten minutes of looking at an agentic system:
- What agents exist across our codebase?
- What tools can agents call, and what can those tools reach?
- If something goes wrong in one tool call, how far does the damage travel?
Right now, answering those questions means piecing together knowledge scattered across engineers, repos, and configurations. The diagrams, threat models, and inventories needed to bring those people into the same conversation typically take days of manual preparation before a review can even begin.
The risk doesn’t live in any single component. It lives in what your agents can reach, and most teams have no map of that.
Trent’s threat analysis for agentic workloads is built to close that gap. You point it at the repos that make up your agentic system, and what comes back is a threat model, a complete inventory (agents, tools, skills, MCP servers, sub-agents), a threat score, and a prioritized remediation plan. This helps your engineering team find and fix the risks that matter before you ship.
Recently, Trent scanned a widely used open-source project to show what this looks like in practice. The open-source project runs autonomous coding agents that can plan, write, and apply changes across a codebase. It spans multiple repos including backend, frontend, and an SDK which gives users a modular toolkit for building custom agents with tools like terminal access, file editing, and task tracking. Trent can scan across repos into a single project, so the analysis covers the system as a whole. We follow responsible disclosure: we work with project owners to close the gaps we find and don’t publish identifying details. So for the specific walkthroughs below – the inventory, the capability graph, the attack chains – we reference a separate agentic app we built in-house and deliberately left vulnerable.
Threat & vulnerability analysis: security requirements tailored to agentic code
When you scan an agentic repo, the first thing Trent produces is a set of security requirements tailored to the nature of the code. For a traditional SaaS codebase, you’d see goals around credential security, authorization, access control, and webhook validation. For an agentic codebase, Trent identifies those same fundamentals and then layers on agentic-specific security goals drawn from its internal knowledge base. The system recognizes that it’s looking at an agentic platform and an agent SDK, and the requirements it generates reflect that. Your team can then steer the requirements to match their specific needs.
From those requirements, Trent builds a threat model grounded in the system’s actual architecture, then surfaces the vulnerabilities that follow from it. It generates data flow diagrams that draw security boundaries between components, and an architecture diagram that gives you the system overview. Each vulnerability is traceable: you can dive into it, ask the Trent Security Advisor for detail, and see exactly where in the code the risk lives.
The inventory: agents, tools, skills, and how they connect
Trent’s threat analysis creates an inventory of every agentic component Trent can identify in the codebase, including agents, tools, skills, MCP servers, infrastructure, and sub-agents. Each item comes with evidence: references back to the exact code that defines it, and for a tool, the description the agent reads at runtime. That description is part of the attack surface. A hidden instruction planted in it, or in a web page or MCP response the tool returns, is something the agent may act on, so surfacing it in the inventory is where that exposure becomes visible.
For the open-source project Trent scanned, the inventory surfaced two distinct agents. The platform itself is agent-based: it’s the orchestrator that manages all AI-driven tool interactions. Separately, the SDK contains a runtime agent that users can configure and extend by invoking predefined skills. That means two agents, two repos, two different capability profiles, with one unified inventory. That inventory is the foundation for everything else in the threat analysis: the deployment-readiness score, the agent capability graph, and the attack chain analysis all build on it.
Below, you can see how an inventory is constructed and visualized for the vulnerable-by-design repo:
The threat score: How deployment-ready is your agentic system?
From the inventory, Trent computes an overall threat score:
- How many of your agentic components have controls in place
- How broad is your trust surface
- How many attack chains have mitigations
- How much work is left before the system is production-safe
The threat score comes with an agentic system overview (your agentic footprint, trust services, containment model, and defense layer) and a set of top-priority action items representing the highest-leverage improvements you can make.
For the open-source project scan, Trent surfaced 14 vulnerabilities across the 2 repos and suggested 15 prioritized mitigation controls. The top risk cluster centers on command injection and prompt injection paths where unsanitized external input reaches agent execution, and on the absence of approval gates for consequential agent actions. Those two themes represent the core attack surface for many agentic systems: code execution paths and behavioral redirection.
Trent identifies and catalogs every agentic component with evidence. That makes it possible to build something most teams have never had: a deep understanding of their agent capabilities.
The agent capability graph: mapping what your agents can actually reach
The capability graph is a visual representation of your agentic architecture. In practice, artifacts like this are what kick off cross-team AppSec reviews. They give security engineers, developers, and infrastructure teams a shared picture to reason from. Trent generates them from the scan instead of needing a human to do the tedious, time-consuming work of preparing them by hand.
Let’s see how the agent capability graph works in practice by walking through the findings for the vulnerable-by-design repo:
- The agent capability graph starts at the agent level.
- Click into the agent and you see every tool it can invoke: browser navigation, terminal, file editing, and others.
- Click into a tool and you see its dependencies.
The orchestrator agent, for example, can invoke run_shell, a tool that executes shell commands. That’s by design, but the command string comes straight from the model’s output with no allowlist or validation, so a compromised or misused tool call can run anything the process can. The fetch_url tool can make outbound requests to any host. Each tool is a node in the graph, and the blast radius of any single agent becomes visible as the set of everything reachable through its tool chain: the filesystem through read_file, the customer database through lookup_order, refunds through issue_refund.
The delegated sub-agent shows a different shape. The orchestrator hands it tasks through delegate_to_sub_agent, and the sub-agent runs with the tools and context it inherits. The graph shows what carries across that boundary: the sub-agent picks up the parent’s reach, including read_file, without the tenant identity being re-derived at the handoff.
Attack chains: where the risks compound
Trent shows what each agent can reach, and it shows how an attacker could string those reaches together. That second view is the attack chains: the multi-step paths where one weakness feeds the next.
For the scanned vulnerable-by-design repo, Trent traced seven chains, all of them unmitigated, grouped by where they start. One begins with a prompt injection in a customer message. The orchestrator reads it, calls lookup_order on another tenant’s order, then calls issue_refund to pay it out: three components, no single one of them broken in isolation. Another runs from an unauthenticated MCP server straight to arbitrary code execution through a single exposed tool. A third starts with SQL injection and ends in data exfiltration through a chain of three tools. Each chain names the components it crosses and the controls that would break it. The relationships between components carry the risk, not any single component alone.
Trent’s attack chain analysis helps customers mitigate ASI08, Cascading Failures – one of the ten risks in OWASP’s Top 10 for Agentic Applications. It’s the risk of a compromise in one agent spreading through the tools and agents that trust it, until a single entry point reaches far beyond itself.
Data sensitivity: contextual analysis, not content analysis
Data access is one of the questions inside “What can those tools reach?” This is a big problem in the industry. Just look at all the companies and investment piling into the Data Security & Posture Management (DSPM) space. Trent answers this question with context-based static analysis.
Trent analyzes design docs and source code to understand how an agentic system interacts with data. To be clear, Trent is looking at the data schema, context, and architecture (not the data contents) to judge data sensitivity, and that line is deliberate.
Trent doesn’t crawl the data itself, for two reasons: crawling the contents of every store an agent can reach is slow and expensive, and your sensitive data should never have to pass through a scan to be mapped. Reading how the system stores, manages, and grants access to data is quicker, more token-efficient, and it keeps your sensitive records private.
The sensitivity picture isn’t a separate report; it’s woven through the findings. Trent first classifies the data each asset holds, then maps which agents and tools can reach those assets and through which credentials. Everything downstream builds on that map. A data-exfiltration threat isn’t raised unless Trent can cite the code that actually handles the sensitive data. An attack chain traces where that data could travel, down to the secret names a CI/CD agent can reach. And the executive summary names the specific dataset at risk, so the report leads with what you stand to lose.
Closing the loop: remediate, rescan, track progress
Traditional scanners stop at the finding. They hand you a list and their job ends, but the actual work of understanding the fix, implementing it, and verifying it landed, falls on your team.
Trent’s MCP server integration closes that loop inside your development environment. In practice, the workflow looks like this:
- Connect the Trent MCP server in Claude Code.
- Ask Trent to summarize the threat analysis for the current repos.
- Trent comes back with the overall threat score, the top critical threats, and the summarized attack chain analysis.
- Pull the prioritized remediation plan. Pick one task or a few.
Claude Code implements the changes, and after implementation, it talks directly back to Trent’s Security Advisor to verify the fix actually addresses the vulnerability, not just the symptom. Once the changes are committed, an incremental scan re-analyzes the delta. In our walkthrough, two tasks implemented, two vulnerabilities resolved, threat score updated.
Trent also tracks results across scan versions, so your team can trace how the threat analysis has evolved over time. The full cycle (detect, plan, implement, verify, track) runs inside Claude Code without switching tools or opening a ticket, so security is embedded in how your team ships software.
Start with what your agents can reach
Securing an agentic system starts with knowing what you’re running: what agents exist, what they can reach, and where the gaps are. For most teams today, that picture doesn’t exist anywhere. Now it does. Scan your agentic repos through Trent and see the threat analysis for yourself.
