AI agents are moving from generating information to taking action.
They retrieve data, call APIs, query databases, execute workflows, update records, and interact with enterprise applications. Protocols such as MCP make these connections easier to standardize and build.
That creates an important shift for enterprise security.
Your AI agent isn’t the only thing you need to secure. Every tool it can call is part of your attack surface.
For organizations deploying agentic AI, the security boundary is no longer limited to the model or application layer.
It increasingly looks like:
Model → Agent → MCP → Tool → Enterprise System
Each connection introduces another dependency that can influence what an agent sees, what it decides, and what actions it can take.
The new AI tool supply chain
Traditional AI security discussions often focus on the model: model access, prompt injection, data leakage, or unsafe outputs.
Those remain important.
But an agent creates another problem: capability.
An AI system with no access to enterprise systems can produce a bad answer.
An AI system with access to enterprise tools can potentially take a bad action.
That distinction changes the security equation.
A compromised or poorly governed tool could expose sensitive data, return manipulated information, provide unsafe instructions, or enable an agent to perform actions beyond its intended scope.
The result is a new supply-chain problem.
The question is no longer simply:
“Can we trust this AI model?”
It becomes:
“Can we trust every component the AI agent is allowed to use?”
For CTOs, six areas deserve particular attention.
1. MCP Server Trust
The first question is straightforward:
Do we know and trust the MCP server connecting the agent to the tool?
An MCP server becomes part of the agent’s execution path. Its implementation, configuration, dependencies, and maintenance practices can therefore affect the security of downstream systems.
Enterprises should establish clear criteria for which servers can enter the environment rather than treating every available integration as an ordinary developer dependency.
Trust should be explicit not assumed.
2. Tool Permissions
Agent capabilities should follow the principle of least privilege.
If an agent only needs to read customer records, does its connected tool also allow updates or deletion?
If an agent needs access to one system, why does the tool expose five?
This is where traditional identity and access management principles need to extend into agentic architectures.
For every tool, organizations should understand:
- What can the tool access?
- What actions can it perform?
- Which agents can call it?
- Which users or workflows authorize those actions?
The goal is simple: an agent should have only the capabilities required for its intended workflow.
3. Provenance
Not every tool should be treated equally.
CTOs need visibility into where a tool came from, who maintains it, what code it depends on, and how it changes over time.
This is particularly important as AI tool ecosystems expand.
A tool may look harmless at the interface level while introducing risk through its dependencies, implementation, configuration, or instructions.
Provenance therefore becomes part of AI governance.
Before connecting a tool to a production agent, organizations should be able to answer:
Who created it? Where did it come from? What has changed? And who is responsible for it?
4. Isolation
Assume that eventually, something will fail.
The question is what happens when it does.
A compromised tool should not automatically provide a path into every system available to the agent or surrounding infrastructure.
Isolation limits the blast radius of a compromised component.
This can include separating sensitive workloads, restricting network access, isolating execution environments, and creating clear boundaries between tools and critical enterprise systems.
The objective is not to assume every tool is malicious.
It is to ensure that one compromised component does not become an enterprise-wide incident.
5. Monitoring
Traditional application monitoring tells you whether a system is working.
Agentic systems require another layer of visibility:
What is the agent actually doing with its tools?
Organizations need to understand tool invocation patterns, unusual access, unexpected sequences of actions, and activity that falls outside the agent’s normal workflow.
Monitoring should therefore extend beyond infrastructure health.
It should provide visibility into the behavior of the agent-to-tool relationship.
Without that visibility, organizations may discover a security problem only after the tool has already been misused.
6. Runtime Enforcement
Policies are useful only if they can be enforced when an action happens.
An agent may be authorized to use a tool, but that does not mean every individual action should automatically be allowed.
Runtime controls can provide a final decision point before an action reaches an enterprise system.
Depending on the workflow, that could mean:
- blocking high-risk actions,
- requiring human approval,
- restricting sensitive parameters,
- enforcing transaction limits, or
- preventing access outside an approved scope.
This creates an important distinction:
Authorization determines what an agent can potentially do. Runtime enforcement determines what it can actually do in a given situation.
From AI Security to AI Tool Security
MCP does not inherently make an enterprise environment insecure.
The bigger issue is architectural.
As organizations connect more tools to more capable agents, the number of security dependencies grows with the agent’s capabilities.
That means AI security architecture needs to evolve accordingly.
A useful starting framework is:
Trust → Permissions → Provenance → Isolation → Monitoring → Enforcement
Together, these controls create a security layer around the AI tool supply chain.
And this changes how organizations should approach AI readiness.
Before asking:
“Which AI agent should we deploy?”
CTOs should also ask:
“Which tools will this agent be allowed to use and what happens if one of them cannot be trusted?”
The future of enterprise AI will depend not only on better models and more capable agents, but on controlled connections between those agents and the systems they can influence.
The organizations that treat those connections as part of their security architecture not simply as integrations will have a stronger foundation for scaling agentic AI responsibly.