The Shift to Agentic AI

Summary

Securing generative AI is a moving target because the thing being secured keeps changing shape. Between 2019 and today, AI systems moved through three distinct stages — chatbots, agents, and systems connected via the Model Context Protocol (MCP) — and each stage redraws where the trust boundary sits. This chapter covers that evolution and introduces the Agentic AI Security Framework, an 8-domain model this workshop uses to map security controls across low-code, pro-code, and third-party agents, and to make explicit who owns each control: the platform provider, the customer, or both.

Core concepts

Stage 1 — Chatbots (2019–2022)

In this stage, security was largely about protecting the core model and the infrastructure around it. The AI was a passive entity living inside a well-defined boundary. The trust boundary was simple and static: it existed between the user and a single, centralized model. All trust was placed in that one controlled environment. The user's input was treated as untrusted; the model's output was treated as a direct, unfiltered response from a single source. There was one thing to secure and one place to secure it.

Stage 2 — Agents (2022–2023)

An agent is not one thing — it's a spectrum of autonomy:

• Interactive agents perform a single, specific, repetitive task on demand ("summarize this email") and act only when the user asks.
• Autonomous agents are goal-oriented: they create plans to achieve an outcome and coordinate actions on the user's behalf, on the user's schedule.
• Collaborative agents are learning-driven and emulate human decision-making. They provision their own access and resources, and pursue goals on their own behalf and schedule.

Every step along that spectrum removes a human checkpoint. An interactive agent has a human in the loop for every action. A collaborative agent might not. That's the shift that breaks the chatbot-era security model: the boundary can no longer sit between "user" and "model," because the agent itself is now making decisions and taking actions no single prompt fully describes.

Stage 3 — Model Context Protocol

The most recent stage standardizes how agents discover and use tools, data sources, and other models across organizational boundaries. This is covered as its own deep dive later in the workshop — see Chapter 7: MCP Security — because MCP introduces its own threat surface (credential handling, tool poisoning, session hijacking) distinct from the agent-identity and data problems covered in Chapters 3–4.

The trust boundary, restated

Across all three stages, the same question is being answered differently: where do we stop trusting input and start verifying it? Chatbots answered it once, at the edge of a single model. Agents answer it continuously — at every tool call, every retrieval, every action — because the agent's own reasoning is now part of the attack surface, not just its inputs and outputs.

Architecture discussion — the Agentic AI Security Framework

Rather than treat "AI security" as one undifferentiated problem, this workshop uses an 8-domain framework to map specific controls to specific layers, and — critically — to make explicit who is responsible for each one. Responsibility shifts depending on how the agent is built:

• Low-code — Copilot, Copilot Studio, Agent Builder
• Pro-code — Azure AI Foundry, AKS/EKS, App Services
• Third-party agents — pro-code providers like Gemini or Bedrock, and SaaS agents embedded in tools like Jira or Workday

Responsibility model: Provider-led — the vendor owns the control. Shared — joint responsibility. Customer-led — the customer owns the control. Mapping condensed from the workshop framework; exact tooling per domain is covered in later chapters.

The concrete tooling behind each "Customer" and "Shared" cell in this table is what the rest of this workshop covers: Entra Agent ID for identity and access, Purview and Defender for Cloud Apps for data security and shadow AI, Azure AI Content Safety and the AI Red Teaming Agent for secure SDLC and red teaming, and Defender for Cloud and Agent 365 for runtime security and incident response.

Key security considerations

• The boundary moved from static to per-request. A control that only checks identity once, at login, does not cover an agent that keeps acting for hours or days across many tool calls.
• Autonomy is a spectrum, not a switch. Two agents built on the same platform can carry very different risk depending on where they sit between "interactive" and "collaborative" — assess each agent individually, not by product category.
• Responsibility is not uniform across deployment models. A low-code Copilot Studio agent and a pro-code Foundry agent carry the same identity and data risks, but very different SDLC and red-teaming responsibility. Assuming "the platform handles it" is the single most common gap this framework is designed to catch.
• Third-party and shadow AI is its own domain, not an afterthought. Agents your organization did not build (SaaS agents in Jira, Workday, or a vendor's product) still touch your identity and data surface, even though you don't control their SDLC.

Recommended practices

1. Before evaluating any agent's security posture, place it on the interactive → autonomous → collaborative spectrum first. The answer changes what "sufficient" controls look like.
2. Use the 8-domain table as a literal checklist per agent deployment: for each of the 8 domains, name the specific control and who owns it. An empty cell is a gap, not a "handled by the platform" assumption.
3. Re-run the classification whenever an agent's deployment model changes — for example, when a Copilot Studio prototype graduates to a pro-code Foundry deployment, its SDLC and red-team responsibility shifts from largely provider-owned to customer-owned.
4. Treat third-party and SaaS-embedded agents as agents, not as application features. They still need an entry in your AI asset inventory (domain 01).

Technologies referenced

• Azure AI Foundry — pro-code agent hosting and orchestration platform, covered in depth in Chapter 5.
• Copilot Studio / Agent Builder — low-code agent authoring surfaces.
• Microsoft Entra Agent ID — identity and access domain, covered in Chapter 3.
• Microsoft Purview — data security domain, covered in Chapter 4.
• Microsoft Defender (Defender for Cloud, Defender for Cloud Apps, Defender XDR) — runtime security and shadow AI domains, covered in Chapters 4 and 6.