Agentic AI Security: Why Your New “Helpful” Digital Coworker Needs Least Privilege, Logs, and a Chaperone

Agentic AI is the new office intern who somehow has root access, an expense card, and the confidence to “just ship it.” If that sentence made your security team spill coffee, you’re not alone.

In an excellent OVHcloud Blog post, Julien Levrard (CISO, OVHcloud) breaks down agentic AI “from a security perspective” and, crucially, does it in a way that maps to how enterprises actually work: messy workflows, partial access controls, SaaS sprawl, and lots of “quick POCs” that accidentally become production. The original piece is here: Agentic AI from a security perspective. It’s dated January 8, 2026 and it’s one of the more practical threat-modeling writeups I’ve seen for the current wave of AI agents.

This article expands on Levrard’s foundation with additional industry context, the most relevant security frameworks, and the not-so-fun implications of giving non-deterministic systems the ability to click buttons in your environment. If you’re building, buying, or being voluntold to approve “an AI agent initiative,” this is your field guide.

Agentic AI: a security definition that actually matters

There’s no shortage of marketing definitions for “agentic.” In security terms, the difference between a plain chatbot and an agent is simple:

A chatbot talks. It produces text (and sometimes files) that a human interprets and acts on.
An agent acts. It can call tools, access data sources, and trigger real changes in systems—sometimes with human approval, sometimes not.

Levrard’s OVHcloud post frames agentic AI as an orchestrator: capturing intent, pulling context, iterating with an LLM, and executing actions across services. That “execution” step is where security goes from “annoying compliance checkbox” to “we might have created a new lateral movement layer.” (OVHcloud source)

OWASP’s GenAI guidance puts a name on the central danger: Excessive Agency—granting LLM-backed systems too much autonomy without proper constraints. In OWASP’s Top 10 for LLM Applications (v1.1), this shows up as LLM08: Excessive Agency. (OWASP)

Why agentic AI changes threat modeling (even if your model is “safe”)

Classic application security asks: “Can an attacker run code? Can they bypass auth? Can they exfiltrate data?” Agentic AI adds a new question:

Can an attacker convince your system to misuse its legitimate access?

This is the “confused deputy” problem, updated for 2026 with more tokens.

Prompt injection is not a bug you patch once

Prompt injection—malicious instructions embedded in content the model processes—is widely recognized as the top issue in LLM app security. OWASP ranks it as LLM01: Prompt Injection. (OWASP)

OpenAI has publicly described prompt injection as an “open challenge” for agent security, using the example of an agent reading an attacker’s email and being tricked into forwarding sensitive documents. Their key point is sobering: when agents operate on the open web (or open internal corp web), the attack surface includes any content the agent reads. (OpenAI)

In other words: if your agent reads tickets, emails, chat messages, PDFs, or Confluence pages, you’ve just created a new “instruction channel” that attackers can target.

Insecure output handling becomes a supply-chain of your own making

OWASP’s LLM02: Insecure Output Handling is about what happens when your system blindly trusts what the model outputs—like taking generated code, commands, or URLs and feeding them into something powerful. (OWASP)

Agentic systems amplify this because output often becomes action:

“Run this kubectl command” turns into “run it automatically.”
“Here is the invoice recipient” turns into “send payment.”
“The best fix is to rotate keys” turns into “rotate keys now,” possibly the wrong ones.

It’s automation with an improvisational layer. Improvisation is great in jazz; less great in IAM.

Levrard’s practical taxonomy: not all “AI in apps” is equally risky

One of the strongest aspects of the OVHcloud post is that it avoids lumping everything under “AI = risk.” Instead it categorizes deployments by architecture and integration depth. (OVHcloud source)

Here’s that taxonomy—expanded with what it means operationally for security teams.

1) Conversational agents with no third-party integration

This is the “employee uses a public chatbot to draft an email” model. The agent is not connected to internal systems. The main risk is data leakage via user copy/paste or file uploads, and potential model training or retention issues depending on the provider configuration.

Levrard calls this “classic responsibility framework” with the human in the loop by design. The key control here is governance: awareness, an AI policy/charter, and sometimes blocking access to certain services from corporate networks. (OVHcloud source)

Practical takeaway: This is closer to “shadow SaaS” than “agent security,” but it still needs DLP and clear rules—especially in regulated industries.

2) “AI-augmented” applications (SaaS features that call LLMs)

This is where your existing tools (messaging, video conferencing, CRM, doc suites) start shipping AI features: summaries, translations, “smart replies,” meeting notes. Levrard’s point is that the security model is supposed to remain that of the application vendor, but complexity increases and integrations add new failure modes. (OVHcloud source)

Key risks include:

Over-privileged service accounts used to fetch data for AI features
Prompt injection via content inside the application
Supply chain dependencies (subprocessors, model providers, plugin ecosystems)

Practical takeaway: Treat “AI feature” as a new data processing path. Re-run vendor risk assessments, ask about subprocessor chains, and validate that AI features respect your existing access controls at the data level—not just “the user is logged in.”

3) True agentic AI: the agent as an orchestrator

This is where Levrard’s analysis gets especially useful. He breaks agentic implementations into multiple classes, each with distinct security implications. (OVHcloud source)

Agents integrated into local applications: convenient, and quietly powerful

Think: an office app, email client, or OS feature that can connect to an LLM and perform tasks. Some run the model locally; others call cloud APIs. Levrard highlights the risks you’d expect from any “cloud connectivity added to a desktop app,” plus some LLM-specific ones: default configurations, and leakage of authentication secrets (bearer tokens). (OVHcloud source)

What’s new here is the blast radius of mistakes. Desktop apps already have broad access to user files. If the agent layer can read documents and then send content to a remote model endpoint (or to plugins), you’ve created an exfiltration path that looks like legitimate product functionality.

Recommended controls tend to be very “endpoint security” flavored:

Application allowlists / enterprise app control
Configuration baselines (“AI connectors off by default”)
Network monitoring for model endpoints
Local secrets management

Generalist and developer agents on workstations: the IDE is the new perimeter

Levrard calls out local agents used by developers and power users—often via IDE integrations or desktop apps—with plugin marketplaces and connectors that can reach both local file systems and external services. Examples listed include Claude Desktop, Cursor, GitHub Copilot, and others. (OVHcloud source)

This class is high risk for three reasons:

Local file access (source code, secrets in .env, SSH keys, config files)
Marketplace connectors (third-party MCP servers, plugins, “quick integrations”)
Credential sprawl (OAuth tokens, API keys, bearer tokens stored locally)

It’s also where “security culture” meets reality: engineers will install whatever makes the red squiggles go away. That’s not a moral failing; it’s how incentives work.

Case study pattern: the accidental secret vacuum

A very common failure mode in agent-enabled developer tooling goes like this:

A developer asks an agent to “help debug auth.”
The agent requests project context and reads config files.
The context contains credentials (API keys, tokens, private endpoints).
The agent ships some of that context to a remote model, a third-party tool server, or logs it somewhere unexpected.

None of this requires malware. It’s a workflow vulnerability.

Mitigation idea that actually works: treat developer agents like you treat browsers: sandbox them, restrict filesystem scope, and enforce secrets scanning in repos and working directories. If your org already invested in secret scanning, the “agent era” is your reason to make sure it’s actually enforced.

Remote agents: when the agent is someone else’s web app

Remote agents are web applications that connect to LLMs and third-party services. Levrard’s big point: the hard part is not the model; it’s access to everything else. Remote agents often rely on OAuth delegations so the user can authorize access to corporate systems. That makes the agent a hub for secrets and access tokens. (OVHcloud source)

From an enterprise perspective, this creates uncomfortable questions:

Where are tokens stored?
How long do tokens live?
Can the vendor’s staff access logs, prompts, or tool outputs?
What happens if the agent is prompt-injected while it has access to email, files, and ticketing?

OpenAI’s own guidance for agent usage emphasizes limiting logged-in access when possible and carefully reviewing confirmations before consequential actions. That’s the same general principle Levrard pushes: constrain access and keep humans in the approval chain for high-impact steps. (OpenAI)

Workflow agents: “agents as code” and why security teams should like them

Workflow agent tools (like automation platforms with LLM nodes) can be local or remote. Levrard notes that breaking workflows into smaller parts can improve determinism, testing, repeatability, and the ability to constrain permissions per step. (OVHcloud source)

This is the closest thing we have today to “DevSecOps for agents.” Instead of a single all-powerful assistant, you build a pipeline where:

each component has scoped access
inputs/outputs are validated
logs are centralized
human approvals can be inserted at gates

Security caveat: workflow tools also create “shadow orchestration platforms” when business users spin them up without governance. Levrard explicitly calls out this risk, and it’s real: workflow builders become the new shadow IT because they’re easy, powerful, and marketed as “no-code.” (OVHcloud source)

The connector problem: MCP and the new integration supply chain

Modern agents don’t just call one API. They connect to a growing zoo of tools and data sources. That’s why standards like Model Context Protocol (MCP) have gained traction: MCP aims to standardize how applications provide context and tool access to LLMs—Anthropic famously compares it to a “USB‑C port for AI applications.” (Anthropic)

From a security standpoint, MCP is both helpful and terrifying:

Helpful because standardization can enable consistent auth, auditing, and policy enforcement.
Terrifying because it makes it dramatically easier to wire powerful tools into an agent—sometimes by copy/pasting a config snippet from a tutorial.

Anthropic’s documentation for its MCP connector highlights OAuth support and the ability to connect to multiple MCP servers in a single request. It also notes limitations (for example, certain feature support and deployment constraints), which is a reminder that the ecosystem is still evolving and not uniformly hardened. (Anthropic)

Security implication: MCP servers become a new type of dependency. In classic software, you worry about libraries. In agentic software, you worry about connectors that can take actions.

What should security teams demand from MCP/tool servers?

Whether you’re using MCP or any tool-calling architecture, the controls you need are familiar, but must be enforced harder:

Strong authentication (OAuth with proper scopes, short-lived tokens, rotation)
Authorization at the tool level (not just “the agent is allowed,” but “this specific action is allowed now”)
Policy enforcement (allowlists of tools, deny-by-default for high-risk actions)
Auditing (who invoked what tool, with what parameters, on whose behalf)
Rate limiting and cost controls (LLM-driven loops can DoS you financially)

Those map nicely to Levrard’s emphasis on secret management, limiting scope/duration of rights, and identifying trustworthy intermediaries. (OVHcloud source)

Security frameworks that matter right now

Agentic AI security is moving fast, but you don’t have to invent your own governance from scratch. There are two references that are particularly useful for organizations trying to be systematic:

NIST AI RMF Generative AI Profile (2024)

NIST published the Generative AI Profile as a companion to the AI Risk Management Framework (AI RMF 1.0). It’s designed as a cross-sector resource for incorporating trustworthiness considerations across the AI lifecycle. If your leadership needs a “serious grown-up framework” to justify process, this is it. (NIST)

How to use it pragmatically: map agentic deployments to lifecycle stages (design, development, deployment, operations) and require explicit risk acceptance for any use case that involves tool execution or access to sensitive data.

OWASP Top 10 for LLM Applications

OWASP’s list is valuable because it’s concrete and aligns with how AppSec teams already operate. The moment an agent can call tools, you should assume you’re exposed to at least:

LLM01 Prompt Injection
LLM02 Insecure Output Handling
LLM06 Sensitive Information Disclosure
LLM08 Excessive Agency
LLM05 Supply Chain Vulnerabilities (connectors, model providers, tool servers)

And yes, you can still have all the traditional risks too—because the agent is still software running on infrastructure you still own. (OWASP)

Human-in-the-loop: not a buzzword, a circuit breaker

Levrard makes a blunt observation: because LLMs are non-deterministic, relying solely on the agent’s internal “human-in-the-loop” features is not compatible with sensitive processing. The future, he argues, needs auditable agents and independent control mechanisms: sandboxing, filtering, access management, traceability. (OVHcloud source)

That’s exactly right. “Human-in-the-loop” fails if it becomes a UI checkbox that users click through like cookie banners.

What does effective human-in-the-loop look like?

Step-up approvals for high-impact actions (sending email externally, sharing files, deploying code, making payments)
Clear diffs (show exactly what will be sent/changed, not a vague summary)
Role-based approvals (the person approving is accountable and trained)
Kill switches (easy to disable a tool or revoke tokens org-wide when something goes wrong)

OpenAI’s agent guidance similarly stresses carefully reviewing confirmations for consequential actions and avoiding overly broad prompts that give an agent too much latitude. (OpenAI)

Secrets management is the heart of agent security (and always will be)

If you only remember one sentence from this article, make it this one:

Agentic AI is secrets management with extra steps.

Levrard explicitly puts secret management at the center of the agentic AI problem: constrain access rights in scope and duration, identify trusted intermediaries (especially MCP servers), and avoid rebuilding a whole parallel permissions model. He mentions standards like OAuth2, JWT, SAML, SPIFFE/SPIRE, OPA, and Cedar as building blocks—but warns about complexity and lack of universal reference implementations across today’s fast-moving ecosystem. (OVHcloud source)

This lines up with what we’re seeing in real deployments: teams can often secure the model endpoint, but struggle to securely broker the agent’s access to Gmail, GitHub, Jira, Slack, cloud consoles, and internal APIs.

Minimum viable “agent secrets” strategy

Short-lived tokens wherever possible (minutes, not days)
Fine-grained scopes (read-only by default, separate scopes for write actions)
Per-task permissions (grant access just-in-time for the step, then revoke)
No shared service accounts for agents unless absolutely necessary
Centralized revocation (ability to pull the plug fast)
Logging that includes tool calls and parameters, not just chat transcripts

“The browser will become the agent”: a prediction with real security consequences

Levrard ends with a provocative idea: for the last 15 years, the browser has been the primary access vector into information systems, and browsers have an enormous attack surface. AI agents are changing that paradigm by offering dynamic interfaces and contextual functions—so tomorrow’s browser may effectively be an AI agent (or browsers will become agents). (OVHcloud source)

This isn’t sci-fi. The industry is already experimenting with agentic browsers and “computer use” agents. The security community has also noticed that agentic browsing introduces new vulnerabilities beyond traditional browser security, because the attacker can target the agent’s decision-making rather than a memory corruption bug. OpenAI has discussed this in the context of prompt injection and agent hardening. (OpenAI)

Implication: Security teams may soon need “agent security baselines” the way they have browser baselines today: approved tool sets, restricted sign-in contexts, safe browsing modes, and enterprise policy enforcement.

A practical security checklist for organizations deploying agentic AI

To bring all of this down from “interesting but abstract” to “what do I do Monday morning,” here is a pragmatic checklist aligned with Levrard’s architecture-first approach and OWASP/NIST guidance.

1) Classify your agent type before you argue about controls

Is it a standalone chat tool?
Is it an AI feature inside a SaaS product?
Is it a local agent on endpoints (IDE/desktop)?
Is it a remote agent that holds OAuth grants?
Is it a workflow/orchestration agent with multiple steps?

The controls you need differ dramatically depending on the answer. Levrard’s taxonomy is a good starting model. (OVHcloud source)

2) Treat tool access like production access (because it is)

Least privilege per tool
Separate read vs write tools
Approvals for irreversible actions
Explicit allowlists for which tools the agent can call

This directly mitigates OWASP’s “excessive agency” and limits damage from prompt injection. (OWASP)

3) Assume prompt injection and design for failure

Do not let the model decide what is “trusted instructions” vs “untrusted data”
Implement out-of-band policy checks
Use content isolation patterns (separate channels, structured tool inputs)
Validate outputs before execution

OpenAI’s agent security write-up reinforces that prompt injection is an open challenge and recommends narrowing scope and reviewing confirmations. (OpenAI)

4) Centralize logs and make them reviewable

You want to be able to answer:

Which user triggered which workflow?
What tool calls occurred?
What data left the environment?
What tokens were used, and were any rotated/revoked?

Without this, incident response becomes interpretive dance.

5) Audit the integration supply chain (models, plugins, MCP servers, subprocessors)

Levrard warns about uncontrolled supply chains and subcontractor leakage. This becomes more acute as standards like MCP make it easy to plug in new capabilities. (OVHcloud source)

At a minimum:

inventory all connectors and tool servers
require security reviews for new connectors
define who can approve OAuth grants
ensure you can revoke access quickly

Where agentic AI security is heading in 2026

Based on the current standards push and the trajectory described by OVHcloud, OWASP, NIST, and leading model providers, expect three trends to dominate the next 12–24 months:

1) Standardized connectors will become unavoidable

MCP and similar approaches are reducing integration friction. That’s great for productivity and terrible for “we only integrate after a 6-week security review.” The organizations that succeed will build policy gates and approval workflows around connectors, rather than trying to stop the ecosystem from existing.

Anthropic’s MCP documentation makes clear the goal is standardized connectivity between applications and tools/data sources. Security teams should read it not as “cool developer feature,” but as “new enterprise integration layer.” (Anthropic)

2) “Agent control planes” will emerge

Levrard explicitly calls for independent control mechanisms: sandboxing, filtering, access management, traceability. That reads like a roadmap for a new class of security tooling: an agent security gateway that sits between models and tools, enforcing policy and auditing actions. (OVHcloud source)

3) Governance will move from “AI policy” to “AI operations”

Many companies started with an AI charter (which is still useful). But once agents can act, you need operational discipline: change management, access reviews, incident response playbooks, and testing—especially for workflows that can touch sensitive data.

NIST’s Generative AI Profile is a strong anchor for that operationalization because it’s built to be used across the AI lifecycle. (NIST)

Bottom line

Levrard’s OVHcloud article lands on the right framing: agentic AI is not one thing; it’s a set of architectures, and security risk depends on where the agent sits, what it can access, and how it is controlled. (Original source)

The security posture that works in 2026 looks like this:

Assume prompt injection is possible and design systems that fail safely.
Keep agency bounded using least privilege, scoped tools, and approvals.
Make secrets management first-class, not an afterthought.
Prefer workflow approaches that allow step-by-step control and testing.
Log everything that matters, especially tool calls and data egress.

If your organization gets those right, agentic AI can be more than a shiny demo. It can be a productive layer on top of your systems that doesn’t also function as a self-service breach generator.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org