Most organizations already have AI governance discussions underway. They have policies, working groups, acceptable-use guidance, and long lists of principles around responsible AI adoption. But as enterprises move deeper into agentic AI, many security teams are discovering that governance alone doesn’t translate into operational control.
That gap is becoming increasingly dangerous.
AI systems are no longer isolated tools that employees occasionally interact with in a browser tab. They’re being embedded directly into productivity suites, connected to enterprise infrastructure, and deployed as autonomous agents capable of interacting with sensitive systems and executing real workflows.
The problem is that many organizations are still treating “AI security” as a single category. In reality, the risks (and the controls required to manage them) vary dramatically depending on the type of AI system being deployed.
To operationalize AI security effectively, organizations need a simpler and more structured framework: one that maps specific AI deployment models directly to the runtime control points required to secure them.
Not all enterprise AI carries the same risk
The first step is understanding what the business is actually deploying. Most enterprise AI deployments now fall into three broad categories and the connective MCP layer that increasingly underlies them all, each with very different security implications.
1. Standalone AI tools
These are external AI applications like ChatGPT or Claude that employees use independently. The risks here are relatively familiar and include data leakage, shadow AI usage, and employees exposing sensitive information to systems outside organizational control.
Most security teams already have some experience managing these concerns through acceptable-use policies, DLP controls, and visibility tooling. But standalone AI tools are only the beginning.
2. Embedded models and copilots
Embedded AI systems are significantly more complicated because the AI and the application are tightly connected. Examples include Microsoft 365 Copilot, Google Workspace AI features, developer assistants, and AI-powered enterprise applications.
In these environments, the AI often operates directly within the user’s existing permissions and identity context. That creates one of the biggest security challenges emerging in enterprise AI today: accountability distortion.
If a Copilot exposes sensitive information, accesses data it shouldn’t surface, or takes an unintended action, the activity can appear indistinguishable from legitimate user behavior in logs and audit trails. To the system, it looks like the user performed the action themselves. That makes detection, attribution, and governance significantly harder.
The risk becomes even more serious when you consider the combination of broad permission scoping and the non-deterministic nature of AI systems. A manipulated prompt, hallucinated response, or poorly constrained workflow can produce outcomes that technically operate within a user’s permissions while still creating serious operational or security consequences.
Consider a scenario already playing out in enterprises today: an employee asks Microsoft 365 Copilot to summarize “everything relevant” before a major leadership meeting. The Copilot, operating within the employee’s existing permissions, surfaces files from sensitive HR folders, an unreleased earnings deck, and a confidential M&A workspace the employee technically has access to but rarely opens. The audit trail shows the employee accessed all of it because, structurally, they did. There is no signal in the logs that a Copilot pulled the files; the activity is attributable to the human identity that prompted it. By the time someone realizes sensitive content surfaced in a meeting it shouldn’t have, the attribution problem has already happened.
3. Custom agents
The next wave of enterprise AI adoption involves internally developed agents capable of executing multi-step workflows with limited human oversight at machine speed. These agents are increasingly being connected to ticketing systems, cloud infrastructure, collaboration platforms, code repositories, identity systems, and internal business applications. Unlike traditional automation, they can dynamically decide how tasks are completed and how systems are interacted with.
That changes the security challenge entirely. Organizations are no longer just securing access to data. They are securing autonomous systems capable of taking action inside environments where they already hold legitimate permissions.
A common pattern: an engineering team deploys an internally built agent to triage incoming bug reports. The agent has legitimate access to the ticketing system, the code repository, and an observability platform: exactly the systems a human triage engineer would use. Then, during a production incident, someone extends the agent’s reach to “just look at the logs in staging” to speed up the response. Within weeks, the agent is reading staging databases, pulling configuration from infrastructure-as-code, and surfacing customer-impacting data in shared channels, not because anyone authorized that breadth, but because each individual permission grant felt small in isolation. The agent is operating within its authorized permissions. The blast radius is the problem.
4. MCP infrastructure
Model Context Protocol (MCP) servers are rapidly becoming the connective layer between AI models and enterprise systems, and as agentic deployments scale, they’re increasingly central to how those agents interact with tools and data in real time.MCP infrastructure allows AI systems to retrieve context and interact with tools and applications in real time. Operationally, this creates enormous value. Security-wise, it dramatically expands the attack surface.
Security teams now need visibility into:
- Where MCP servers exist
- What systems do they connect to
- What permissions do they hold
- Which agents are interacting with them
- Whether shadow MCP deployments are operating outside normal governance processes
Without that visibility, organizations risk creating an expanding layer of AI-connected infrastructure operating with legitimate access but very little oversight.
Mapping the security control points
Once organizations understand what types of AI systems they’re deploying, the security conversation becomes much more practical. In most environments, operational AI security comes down to three core areas: visibility, authorization, and monitoring.
1. Visibility & discovery
The first challenge is simply understanding where AI is operating and how it connects to the environment.
Security teams need visibility into standalone AI tools, embedded copilots, internally developed agents, and especially MCP infrastructure. That includes identifying where MCP servers live, what systems they connect to, and whether shadow AI deployments are operating outside normal IT oversight. For many organizations, AI adoption is already moving faster than their ability to inventory and govern it.
2. Authorization & control
Once visibility is established, organizations need clear ownership and strict access boundaries across human users, AI agents, and non-human identities. This becomes especially complicated in embedded AI environments where copilots operate directly within a user’s permissions. Traditional identity and access models were never designed for systems capable of autonomous or semi-autonomous decision-making. As a result, static permissions and broad standing access become significantly riskier in agentic environments.
Organizations are increasingly being pushed toward more dynamic approaches built around continuous authorization, just-in-time access with dynamic privilege creation and revocation, and clearer separation between human and AI-driven activity.
3. Monitoring & threat prevention
Even properly authorized AI systems can behave unpredictably, which makes continuous monitoring essential. Security teams need the ability to detect prompt injection attempts, anomalous behavior, suspicious workflows, and unusual access patterns before an AI system takes an unwanted action inside an environment where it already has legitimate access.
That’s the operational shift many organizations still underestimate. The biggest risks often don’t come from unauthorized access. They come from AI systems acting within their authorized permissions in unintended or dangerous ways. And in many cases, that activity may look operationally normal right up until the moment something goes wrong.
AI security is becoming a runtime problem
Much of today’s AI security conversation still revolves around governance frameworks and high-level policy discussions. Those efforts matter, but they are no longer enough.
As AI systems become more autonomous and more deeply integrated into enterprise operations, security teams will need architectures built around runtime visibility, continuous authorization, and the ability to revoke access at any moment during the session.
The organizations that succeed won’t necessarily be the ones with the most ambitious AI strategies. They’ll be the ones that recognize agentic AI for what it really is: not just a model challenge, but an authorization and operational control challenge.
Art Poghosyan is an entrepreneur and InfoSec expert with over 20 years in cybersecurity. He excels in building high-performance teams and fostering collaborative, accountable cultures. Prior to founding Britive, a pioneering cloud privileged access management (CPAM) platform, he co-founded Advancive, an Identity and Access Management (IAM) consulting firm acquired by Optiv in 2016. Art is a mentor, speaker, and contributor to industry events and (ISC)2 CISSP-ISSAP exam development, deeply committed to advancing cloud security innovations.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.