Most AI agent risk hides in the tools, not the chat box.
A model with no tools can still produce bad advice. A model with file access, database access, ticket access, email access, or API access can turn bad instructions into real action.
That is the line teams keep missing.
Short answer
An AI agent tool inventory is a simple list of every tool an AI system can call, what data each tool can touch, what action it can take, who approves risky use, and what logs exist afterward. It helps teams reduce prompt injection, data leakage, and excessive agency risk by making the agent's real blast radius visible before automation spreads.
The prompt is not the boundary
A lot of AI governance starts with acceptable use language.
Do not paste secrets.
Do not use customer data.
Review AI output before sending.
Those rules help. They are not enough once an agent can call tools.
OWASP's 2025 guidance on prompt injection is blunt about the core problem. Prompt injection can happen when user input or external content changes model behavior in unintended ways. It can come directly from a user, or indirectly through a website, document, email, repository, or retrieval source the model reads.
OWASP also notes that the impact depends on business context, the agency granted to the LLM, and the connected tools, APIs, and permissions available to it.
That is the practical issue.
The same injected instruction has different consequences depending on what the agent can do next. If it can only draft text, the failure mode is reviewable. If it can query customer records, update a ticket, trigger a workflow, or send a message, the failure mode changes.
MCP made this easier and riskier
Model Context Protocol is useful because it gives AI systems a standard way to connect with external tools. The MCP tools specification describes tools that let models interact with external systems like databases, APIs, computation engines, and other services.
That is exactly why teams like it.
It is also why casual adoption gets dangerous.
The MCP specification says tools are model-controlled. The model can discover and invoke tools based on the user's prompt and context. The same specification also says applications should show which tools are exposed, clearly indicate when tools are invoked, and keep a human in the loop with the ability to deny tool calls.
Ready to apply the FORGE framework?
VibeSec Advisory helps knowledge worker teams redesign real processes using the six FORGE pillars: Baseline, Skills, Agents, Guardrails, Schedule, and Capture. The next step is advisory intake, not checkout.
Those are not small UI details. They are guardrails.
If your team cannot answer which tools are exposed, what each one can touch, and when a human can stop the call, you do not have governed agent use yet. You have connected software with unclear boundaries.
The inventory is the control
A tool inventory does not need to be fancy.
Start with one workflow. Then document:
- Tool name
- Business purpose
- Data it can read
- Actions it can take
- Systems it can modify
- Permission level
- Approval required before use
- Log or audit trail after use
- Failure mode if the tool is misused
- Owner who can disable it
That list turns a vague AI risk into a workflow review.
A support agent that can summarize tickets is different from one that can issue refunds. A sales assistant that can draft a follow-up is different from one that can update CRM fields. An internal research agent that can read approved documents is different from one that can search across every shared drive.
The model may look the same from the chat window. The risk is completely different.
Where this fits in FORGE
This is a Guardrails problem, but it starts in Baseline.
Baseline asks what workflow exists today, who owns it, what tools are involved, and what outcome matters.
Guardrails asks what data boundaries, approval points, action limits, escalation rules, and security controls are needed before AI becomes part of that workflow.
A tool inventory connects those two pieces.
It tells you where AI is only helping someone think, and where it is starting to act on the business.
That distinction matters more than the model name.
A practical first pass
Pick one workflow where someone already wants an agent.
Maybe customer support triage. Maybe sales follow-up. Maybe invoice review. Maybe internal research.
Before adding more automation, answer five questions:
- What tools can the agent call?
- What sensitive data can those tools expose?
- What irreversible actions can those tools take?
- Which actions require human approval?
- Where can we see a log after something happens?
If those answers are unclear, do not add more tools yet.
Clean up the boundary first.
The buyer-facing reality
Most teams do not need a 40-page AI policy before they improve AI safety.
They need visibility into how AI is already touching the business.
The fastest useful artifact is often a one-page tool inventory for a single workflow. It shows where the risk lives, who owns the decision, and what has to be approved before the agent gets more autonomy.
That is governed AI adoption in practice.
Not more policy for its own sake. A clearer map of what the agent can actually do.
If you want a lightweight starting point, use the free FORGE Workflow Snapshot to map one AI-assisted workflow and identify the guardrails it needs before automation expands.