Agentic AI systems are operating in production—processing emails, writing code, booking meetings—and many security teams lack a framework to evaluate their risks. The issue isn't about tools; it's about understanding.
You can't secure what you don't understand. Security professionals are approving AI deployments without the hands-on knowledge needed to identify vulnerabilities, data exposure points, or interactions with existing controls.
The Current Landscape
Three categories of AI agents are already embedded in your environment:
General-purpose coding assistants like GitHub Copilot and Claude Code are in your developers' IDEs. They access your codebase, suggest implementations, and increasingly execute commands directly. These tools may have been approved as "productivity tools" without a thorough review of their access patterns.
Vendor-built agents using Model Context Protocol (MCP) connect AI systems to external services such as calendars, databases, and ticketing systems. MCP standardizes interactions with these resources, meaning a vulnerability in one implementation can affect every agent using that protocol.
Custom agents built by internal teams address specific business needs. Marketing might build an agent for drafting social posts, while finance might create one to parse invoices. These teams often focus on capability rather than security boundaries.
The common thread: these agents make decisions and take actions based on natural language inputs. Traditional security controls assume deterministic behavior, but agents are probabilistic.
Key Findings
Expanded attack surfaces through prompt injection. A malicious calendar invite with hidden instructions is a documented attack vector. The agent interprets the embedded commands as legitimate and executes them. Your email gateway won't catch this because the payload is semantic, not syntactic.
MCP creates a new trust boundary. When an agent uses MCP to access your calendar API, CRM, or deployment pipeline, you're extending trust to both the agent and every service it touches. Most teams haven't inventoried these connections or applied the principle of least privilege to agent service accounts.
Security teams lack the vocabulary to evaluate agent risk. When a product team asks to deploy an agent, you need to assess: What data sources does it access? What actions can it take? How does it handle conflicting instructions? What's the rollback procedure if it makes incorrect decisions? Most security questionnaires don't include these questions as they were written for traditional software.
Compliance frameworks don't address agent-specific controls. PCI DSS v4.0.1 Requirement 6.4.3 covers script authorization but doesn't contemplate systems that generate and execute code based on natural language interpretation. SOC 2 Type II criteria evaluate access controls, but your auditor probably hasn't asked how you prevent an agent from being socially engineered through its training data.
The knowledge gap is widening faster than training programs can close it. AI capabilities evolve monthly, while security training cycles run annually. By the time your team completes a course on securing LLMs, the threat model has shifted to multi-agent systems with tool use.
Implications for Your Team
You're being asked to approve technologies you haven't used. That's the core problem.
When developers requested Kubernetes adoption, you could spin up a cluster, break it, understand its failure modes. When they wanted to implement OAuth, you could read RFC 6749 and test the flows. Agentic AI doesn't work that way. You can't learn its security properties from documentation alone because the system's behavior emerges from probabilistic outputs, not deterministic code paths.
Your existing security controls create a false sense of coverage. Network segmentation doesn't stop an agent from exfiltrating data through its normal API calls. WAFs don't detect prompt injection because the malicious payload looks like legitimate user input. Your SIEM alerts on failed authentication attempts, not on an agent being tricked into executing unintended actions.
The business won't wait for you to catch up. Teams are deploying agents because they deliver measurable productivity gains. If security becomes a blocker without offering constructive guidance, you'll be routed around.
Action Items by Priority
Immediate: Build hands-on competency. Install Claude Code or a similar coding assistant. Use it for a week. Try to make it do something it shouldn't. Attempt prompt injection attacks against your own workflows. You need direct experience with how these systems interpret instructions before you can evaluate their security properties.
Week 1: Inventory existing agent deployments. Survey your development, marketing, and operations teams. Document which AI tools they're using, what data those tools access, and what actions they can take. You can't secure agents you don't know about.
Week 2: Map agent access patterns. For each identified agent, trace its data flows and API calls. Which service accounts does it use? What permissions do those accounts have? Create a matrix of agent-to-resource relationships. Apply least privilege—most agents are running with excessive permissions because teams configured them for capability, not security.
Month 1: Establish agent security requirements. Update your security questionnaire to include agent-specific questions. Before approving new agent deployments, require teams to document: input validation approach, output verification process, data access scope, rollback procedures, and logging strategy. Make these non-negotiable.
Month 2: Implement agent-specific monitoring. Your existing SIEM won't catch agent-specific attacks. Add detection rules for: unusual API call patterns from agent service accounts, agents accessing resources outside their documented scope, and agents generating outputs that trigger downstream security events. Start with baseline behavior, then alert on deviations.
Ongoing: Join agent security working groups. Engage with OWASP's AI Security and Privacy Guide. Attend focused training—events like SANSFIRE 2026 are adding agent security tracks. Your understanding needs to evolve as quickly as the technology.
Ongoing: Require security review for MCP integrations. Any new service connection using Model Context Protocol should trigger a security review. Evaluate both the agent's permissions and the security posture of the connected service. A secure agent connecting to an insecure API inherits that risk.
Conclusion
To effectively secure agentic AI, your team must develop a deep understanding of these systems. Traditional security measures are insufficient without foundational knowledge of the technology. Start by building hands-on experience, mapping agent access patterns, and updating security requirements to include agent-specific considerations. Engage with the broader security community to stay informed and adapt as the technology evolves.
