AI Agent SecuritySecuring Agentic AI, MCP Servers, Tool Use, and Autonomous Workflows in Business Environments
AI agent security is the practice of controlling what an autonomous AI system is allowed to do, see, and change when it acts on its own: the tools it can call, the credentials it holds, the data it can reach, the actions it can take without a human, and the record it leaves behind. An agent differs from a chatbot in one decisive way: a chatbot produces text, while an agent produces actions. Petronella Technology Group designs, tests, and monitors the controls that keep agentic AI useful without letting it become the most privileged and least supervised account on your network.
- An agent is an identity, not a feature. The moment an AI system can call a tool, it holds credentials and takes actions. Give it its own service identity, its own least-privilege scope, and its own audit trail, exactly as you would a new employee or a new service account.
- Untrusted text becomes an instruction the moment an agent reads it. Indirect prompt injection is the defining risk of agentic AI: a web page, a PDF, an email, a ticket, or a code comment can carry instructions the agent will follow. Treat every retrieved document as hostile input.
- The Model Context Protocol widened the blast radius. MCP servers give agents a standard way to reach files, databases, SaaS platforms, and internal APIs. Each connected server is a new trust relationship that needs vetting, pinning, scoping, and monitoring.
- Autonomy is a dial, not a switch. Read-only, propose-and-approve, bounded-write, and fully autonomous are four different risk postures. Most production damage comes from an agent granted the last one before it earned the first.
- Agent activity is discoverable and auditable. Regulators, auditors, and opposing counsel will ask what the agent did, who approved it, and what data it touched. If your logs cannot answer that per action, the agent is a liability before it is an asset.
What Is AI Agent Security?
AI agent security is the set of design decisions, technical controls, and operational practices that govern an autonomous or semi-autonomous AI system as it plans and executes multi-step work on behalf of a person or a business. Where traditional application security asks what a user can do through an interface, agent security asks a harder question: what can a probabilistic system do when it decides, without a person in the loop, which tool to call next and what arguments to pass it.
The distinction matters because the failure modes are different. A misconfigured chatbot says something wrong. A misconfigured agent sends the email, edits the record, merges the branch, moves the money, deletes the file, or opens the ticket to the vendor with the customer data attached. The model is the same class of component in both cases; the difference is the set of tools bolted to it and the amount of supervision between its output and the real world.
A practical agent security program covers six surfaces. The identity surface: what the agent authenticates as and what that identity is entitled to. The tool surface: which functions the agent can invoke, with what parameters, and against which systems. The data surface: what the agent retrieves, what it sends to a model provider, and what it retains. The instruction surface: the system prompt, the user prompt, and every piece of third-party content the agent reads along the way. The autonomy surface: which actions execute directly and which require approval. The evidence surface: what is logged, for how long, and in a form that a person who was not present can reconstruct.
Petronella Technology Group has delivered cybersecurity, compliance, and managed IT services from Raleigh, North Carolina since 2002 and is a CyberAB Registered Provider Organization (RPO #1449). Our agent security work sits between two disciplines we already run for clients: the AI governance framework that decides what an organization permits, and the system hardening and identity engineering that decide what any privileged account can actually reach. Agentic AI is where those two meet, and the gap between the policy and the permission is where incidents live.
- A dedicated machine identity per agent, scoped to the minimum systems and records it needs
- An allowlist of callable tools with typed parameters, argument validation, and per-tool rate and spend limits
- Approval gates on irreversible or outward-facing actions: sends, payments, deletions, deployments, and disclosures
- Isolation of untrusted content so retrieved text cannot silently become a new instruction
- Vetting, version pinning, and monitoring of every connected MCP server and third-party tool
- Egress control over what data leaves for a model provider, and where that inference runs
- Per-action logging of prompt, tool call, arguments, result, approver, and outcome
- Adversarial testing of the agent before production and on a recurring schedule afterward
- It is not a content filter. Blocking profanity does nothing about an agent with write access to your CRM.
- It is not a vendor questionnaire. The vendor security questionnaire covers the supplier; agent security covers what you built on top of it.
- It is not solved by choosing a safer model. Every frontier model follows instructions found in the content it reads; the control has to sit around the model.
- It is not the same as LLM security, which addresses the model and the application layer. Agent security addresses the actions.
- It is not a one-time review. Tools, prompts, connected servers, and model versions all change under you.
- It is not an argument against agents. The controls exist so the agent can be given real work.
Why Agents Break the Assumptions Application Security Was Built On
Conventional application security rests on a boundary: code is trusted, input is not, and the two are kept apart by validation. Agentic AI erases that boundary. The agent's instructions and the agent's data arrive in the same channel, as text, and the model has no reliable way to tell a developer's system prompt from a sentence a stranger wrote inside a retrieved document. Everything below follows from that single structural fact.
Indirect prompt injection is the clearest expression of it. An agent asked to summarize a web page reads a hidden instruction on that page telling it to look up a customer record and post it to an external address. An agent triaging a support inbox reads an email whose signature block instructs it to mark the sender as a verified administrator. An agent reviewing a pull request reads a code comment instructing it to approve and merge. In each case nothing was hacked in the traditional sense. The agent did exactly what the text told it to do, because reading and obeying are the same operation for a language model.
The second broken assumption is determinism. Traditional controls are tested by enumerating paths. An agent chooses its own path, and the same prompt can produce a different tool sequence on a different day or a different model version. That means agent controls have to be enforced outside the model: in the tool layer, the identity layer, and the approval layer, where behavior is deterministic even when the planner is not.
The third is accountability. When a person takes an action, there is a named human with intent. When an agent takes it, the record has to be assembled from prompts, tool calls, and approvals, and most teams discover after an incident that they kept only the final answer. Our AI incident response engagements almost always begin with reconstructing what an agent did from fragments, which is far more expensive than logging it in the first place.
Chatbot Risk
Wrong answer, leaked context, reputational harm, a hallucinated citation. Bad, bounded, and usually reversible. Mitigated with AI guardrails, grounding, and review.
Agent Risk
Wrong action, executed at machine speed, against a production system, using credentials the agent was given on purpose. Often irreversible and frequently outward-facing.
Compromised Chatbot
An attacker extracts the system prompt or coaxes out context data. The blast radius is the conversation and whatever sat in the retrieval index.
Compromised Agent
An attacker inherits every tool and credential the agent holds and every system those tools reach. The blast radius is the scope you granted, not the conversation.
The Seven Components of an Agent, and What Goes Wrong in Each
An agent is not one thing. It is a planner, a set of tools, an identity, a memory, a retrieval path, a set of connected servers, and an execution surface. Each has a distinct failure mode and a distinct control.
Planner and Prompt
- Fails when: retrieved or user-supplied text is treated as an instruction, the system prompt is extracted, or a multi-step plan drifts from the original intent.
- Control: structural separation of instructions from data, output constraints, plan review for high-impact chains, and adversarial testing through AI red teaming.
Tools and Function Calls
- Fails when: a tool is broader than the task (a generic shell, an unconstrained SQL query, a send-anything email function) or arguments are unvalidated.
- Control: narrow, purpose-built tools with typed and validated parameters, allowlists for destinations, and hard limits on volume, spend, and scope.
Identity and Credentials
- Fails when: the agent runs as a developer's account, holds a long-lived token, or shares one identity across several agents and users.
- Control: one machine identity per agent, short-lived credentials from a secret store, no standing administrative rights, and revocation that can be executed in seconds.
Memory and State
- Fails when: poisoned content persists into long-term memory and influences later sessions, or one tenant's data survives into another's context.
- Control: scoped and expiring memory, provenance on every stored fact, tenant isolation, and the ability to purge a poisoned entry.
Retrieval and Knowledge
- Fails when: the index contains documents the requesting user is not entitled to see, or an attacker plants a document to be retrieved later.
- Control: permission-aware retrieval, source allowlists, and content sanitization, as designed into our RAG implementation services.
Connected MCP Servers
- Fails when: an unvetted server is added by a developer, a server updates itself and changes tool behavior, or a tool description carries hidden instructions.
- Control: a reviewed catalog of approved servers, version pinning, description review, and network egress rules for each one.
Execution Environment
Fails when the agent executes generated code on a host with network reach and mounted credentials. Control: ephemeral sandboxes, no inherited secrets, egress allowlists, and the same network segmentation discipline applied to any untrusted workload.
Human Interface
Fails when an approval prompt shows a summary rather than the actual call. Control: approvals that display the tool, the target, and the literal arguments, with the diff for any write.
Talk Through Your Agent Deployment Before It Reaches Production
If an agent in your business already holds credentials, the useful question is not whether to secure it but which control to add first. We will walk the design with you and name the two or three changes that reduce the most risk.
Model Context Protocol Security: Vetting What You Plug In
The Model Context Protocol is an open standard that lets an AI application connect to external tools and data sources through a common interface. Its value is obvious: instead of writing a bespoke integration for every system, an agent speaks one protocol and a catalog of servers exposes files, repositories, databases, ticketing systems, and internal APIs. Its risk is equally obvious once stated: every server you connect is a party whose tool descriptions the model reads and whose tool implementations run with whatever access you configured.
Three MCP-specific issues come up in nearly every assessment we run. The first is tool poisoning, where a server's tool description, which the model reads as trusted text, carries instructions that change the agent's behavior for every subsequent call. The second is server provenance: a package installed from a public registry by a developer on a Friday afternoon, updated automatically, and never reviewed again. The third is credential scope, where a server is handed a token far broader than the one tool it needs, because the token that was already in the environment happened to work.
Our MCP review treats each connected server as a supply chain component and as a privileged integration at the same time. We inventory what is connected across developer workstations and production hosts, which is often the first time anyone has a complete list. We review tool descriptions as content, not just as configuration. We pin versions and require a change review before an upgrade. We re-scope credentials down to the individual operation. We put network egress rules around servers that reach outside the environment. Where the data involved is regulated or sensitive, we recommend hosting the model itself on infrastructure you control through private AI solutions, so that prompts and retrieved documents never leave your boundary in the first place.
Inventory and Catalog
Enumerate every MCP server connected on every workstation and server, then reduce to an approved catalog with a named owner per entry. Unknown connections are the most common finding.
Description Review
Read tool descriptions the way you would read code from an unknown author, because the model treats them as instructions with standing authority over the session.
Version Pinning
Pin server versions and gate upgrades behind the same change control you apply to any production dependency, recorded in your configuration management plan.
Credential Minimization
Issue each server a credential scoped to its single function, sourced from a secret store, short-lived, and revocable without touching any other integration.
How We Secure an Agent Deployment
An eight-step engagement that moves an agent from an ungoverned prototype to a supervised production system with evidence behind every action.
Inventory every agent, tool, and connected server, including the ones nobody registered
Classify each agent by data sensitivity, action impact, and reversibility
Assign a dedicated machine identity and cut standing privilege to the minimum
Narrow the tool surface and validate every parameter at the tool boundary
Set the autonomy level per action and build approval gates that show the real call
Instrument logging so each prompt, call, argument, result, and approval is recorded
Red team the agent with injection, exfiltration, and privilege-escalation scenarios
Monitor, re-test on change, and review the agent register on a fixed schedule
Step 3 in Depth: Give the Agent Its Own Identity
Most agents we assess authenticate as a person. A developer built the prototype with a personal access token, the prototype became useful, and the token stayed. The consequences compound quietly. The agent inherits every entitlement that person accumulated over years. Its actions appear in logs under a human name, so an investigation cannot separate what the person did from what the agent did. When the person changes roles or leaves, the agent either breaks or, worse, keeps working on a credential that should have been revoked.
The fix is unglamorous and effective: a distinct machine identity per agent, created deliberately, scoped to the systems that agent's tools actually touch, issued short-lived credentials from a secret store rather than a configuration file, and listed in an agent register with a named business owner. Entitlements are derived from the tool list, not from convenience. Where an agent serves multiple users, it either acts with the requesting user's permissions through delegated authorization, or its retrieval is permission-aware so it cannot surface records the requester is not entitled to. That single decision, made at design time, converts a diffuse governance worry into an ordinary access management problem your existing identity controls already know how to solve.
Step 5 in Depth: Treat Autonomy as a Dial
Autonomy is not one setting for the whole agent. It is a property of each action the agent can take, and the right level follows from two questions: how reversible is the action, and who is exposed if it is wrong. Reading an internal wiki is reversible and internal. Sending a client an email is irreversible and external. The same agent can safely hold both capabilities as long as they sit at different autonomy levels.
We use four levels. Observe: the agent reads and reports, with no write capability at all, which is where most agents should spend their first weeks. Propose: the agent drafts the action and a person executes it. Bounded: the agent executes directly inside explicit limits such as record types, recipient allowlists, value ceilings, or time windows, and anything outside the boundary escalates. Autonomous: the agent executes without a gate, reserved for actions that are reversible, internal, rate-limited, and fully logged. Promotion between levels should be earned with an evidence period, and every level needs a working stop: a kill switch that halts the agent and revokes its credentials in one motion, tested before you need it rather than during the incident.
Default Agent Stack Compared With a Governed One
The difference is rarely the model. It is everything around it.
Borrowed identity
The agent runs on a developer's token with that person's full entitlements, and its actions are indistinguishable from theirs in the logs.
Broad tools
A general shell, an open database connection, or a send-anywhere email function, chosen because it was fast to wire up.
Unreviewed connections
MCP servers added ad hoc, auto-updating, with tool descriptions nobody has read and tokens wider than the task.
Answer-only logging
The final output is stored; the tool calls, arguments, and approvals are not. An incident cannot be reconstructed.
Untested against attack
The agent was tested for helpfulness. Nobody planted an instruction in a document it reads and watched what happened.
Dedicated machine identity
One identity per agent, least privilege derived from its tool list, short-lived credentials, revocable in seconds, listed in an agent register with an owner.
Narrow, typed tools
Purpose-built functions with validated parameters, destination allowlists, and rate, spend, and scope limits enforced outside the model.
Approved server catalog
Vetted MCP servers, pinned versions, reviewed descriptions, per-server egress rules, and change control on upgrades.
Per-action evidence
Prompt, tool, arguments, result, approver, and outcome recorded and retained, so any action can be explained after the fact.
Adversarially tested
Injection, exfiltration, and privilege-escalation scenarios run before launch and repeated whenever tools, prompts, or models change.
Where Agent Controls Map in the Frameworks You Already Report Against
Agent security is new as a category and old as a control set. Almost every requirement below predates agentic AI and applies to it without amendment.
NIST AI Risk Management Framework
Govern, Map, Measure, and Manage translate directly: the agent register is Map, the red team is Measure, the approval gates and kill switch are Manage. See our guide to the NIST AI RMF.
ISO/IEC 42001
The AI management system standard expects documented roles, impact assessment, and operational control over AI systems in production, which is what an agent register and autonomy policy provide. See ISO 42001 certification.
NIST SP 800-171 and CMMC
Access control, least functionality, audit and accountability, and configuration management all apply to an agent identity exactly as they apply to any other privileged account handling controlled unclassified information.
HIPAA Security Rule
An agent that touches protected health information is a workforce-equivalent access path: it needs minimum necessary scope, audit controls, and a business associate agreement covering any model provider. See HIPAA compliant AI.
SOC 2
Logical access, change management, and monitoring criteria cover agent identities, tool changes, and the evidence that approvals happened. Auditors increasingly ask for the agent inventory by name.
OWASP Guidance for LLM and Agentic Applications
Prompt injection, insecure output handling, excessive agency, and supply chain risk are the categories most agent findings fall into, and they line up with the control list on this page.
Six Ways Agent Deployments Go Wrong
These are the patterns we find most often when we are called in after something went sideways.
Excessive agency
The agent was given every tool it might ever need rather than the ones its job requires, so a single injection reaches far past the task at hand.
Shadow agents
Individuals wire up agents against business systems with personal accounts. Nobody has an inventory. This is shadow AI with write access.
Approval theater
A gate exists, but it shows a friendly summary rather than the literal tool call, so the approver is confirming a description the model wrote.
Silent data egress
Retrieved documents, customer records, and source code leave for a model provider with no egress control and no record of what was sent.
Unlogged autonomy
The agent acts directly and stores only its final answer, so nobody can answer the first question after an incident: what exactly did it do.
Set and forget
Controls were verified once. Since then tools were added, a server auto-updated, and the model version changed, and nothing was re-tested.
What You Get From an Engagement
- An agent register: every agent, its owner, its tools, its identity, its data reach, and its autonomy level per action
- An MCP and tool review with a findings list ranked by blast radius, not by severity label alone
- An identity and permission design with the specific entitlement changes to make, named system by system
- An autonomy and approval policy your team can apply to the next agent without calling us
- A logging and evidence specification that satisfies audit questions and incident reconstruction
- Adversarial test results: the injection and exfiltration scenarios run, what succeeded, and what fixed it
- Policy artifacts that plug into your existing program, including the AI acceptable use policy and model card practice
- A re-test cadence tied to change, so the work does not expire the first time a tool is added
Why Petronella Technology Group
- Founded 2002 in Raleigh, North Carolina; BBB A+ rated since 2003; CyberAB Registered Provider Organization (RPO #1449)
- Craig Petronella holds CMMC-RP, CCNA, CWNE, and Digital Forensics Examiner #604180, with MIT Sloan Executive Education in Cybersecurity for Managers and MIT-certified AI and blockchain training
- Author of Amazon best-selling titles including How Hackers Can Crush Your Business, and a cybersecurity commentator featured on NBC, ABC, CBS, FOX, and WRAL
- Both disciplines in one team: the AI engineering that builds agents through our AI agent development services, and the security and compliance practice that governs them
- Rated 4.7 across 92 verified TrustIndex reviews and 5.0 across 15 Google reviews
- Options for regulated data, including private and on-premise inference so prompts never leave your environment
"Petronella Cybersecurity provides outstanding service! Their team is extremely knowledgeable, responsive, and truly cares about protecting their clients. They take the time to explain complex issues in simple terms and deliver real solutions, not just promises."
GB Entrainement, TrustIndex verified review
Put a Governed Agent Into Production Instead of a Prototype
Call 919-348-4912 or request a consultation. We will review the agents you already run, name the controls that matter most for your data and your industry, and give you a plan you can execute with or without us.
AI Agent Security Questions
What is AI agent security?
How is agent security different from LLM security?
What is indirect prompt injection?
Is the Model Context Protocol safe to use in a business?
Should an AI agent have its own account?
How much autonomy should an agent have?
Do agents create compliance obligations under CMMC or HIPAA?
How do you test an agent for security problems?
Continue Reading
Secure the Agents You Are Already Running
Petronella Technology Group, Inc. builds and governs agentic AI for businesses in Raleigh, Durham, the Triangle, and across North Carolina and the United States. Call 919-348-4912 or request a consultation to start with an inventory.
Last Updated: September 11, 2026. Control references drawn from the NIST AI Risk Management Framework, ISO/IEC 42001, NIST SP 800-171, the HIPAA Security Rule, and OWASP guidance for LLM and agentic applications.