June 26, 2026

Stop Treating Agents Like Service Accounts

AI agents are often managed like traditional service accounts—but that mindset creates serious security and governance risks. This episode explains why AI agents should be treated as autonomous digital identities with their own lifecycle, permissions, and accountability instead of static technical accounts.

The discussion highlights that agents don't just authenticate to services—they make decisions, access business data, trigger workflows, and interact with multiple systems. Because of this, identity becomes the primary security boundary. Organizations should assign every agent its own identity, apply least-privilege access, enforce Zero Trust principles, and continuously monitor behavior rather than relying on broad, long-lived permissions.

The episode also covers the importance of lifecycle management for non-human identities. Just like employees, AI agents require onboarding, role assignments, permission reviews, auditing, and secure decommissioning. Without proper governance, organizations risk identity sprawl, excessive privileges, compliance violations, and increased attack surfaces.

Finally, the podcast argues that successful enterprise AI isn't just about building capable agents—it's about governing them. Strong identity controls, policy enforcement, behavioral monitoring, and clear ownership are essential for creating AI systems that are secure, auditable, and scalable. Treating agents as first-class identities rather than service accounts is the foundation for trustworthy enterprise AI.

Stop treating agents like service accounts. You expose your organization to unnecessary risk by ignoring the unique identity challenges that ai agents bring. The M365 FM Podcast reveals how this outdated approach leads to dangerous gaps in security and governance. Shadow Agents now appear in high-velocity environments, often using shared credentials and operating without oversight. Consider that nearly 40% of non-human identities become orphaned, and only 28% of organizations feel confident in rapid recovery after a breach. You need a new mindset—one that recognizes agent-specific identity management as essential for protecting your data, reputation, and compliance.

Key Takeaways

Recognize that AI agents require unique identity management. Treating them like service accounts exposes your organization to security risks.
Implement centralized tracking for agent identities. This helps close governance blind spots and ensures accountability.
Adopt risk-based governance models. These models allow you to monitor agent behavior in real time and adjust permissions dynamically.
Use scoped and ephemeral access for agents. This limits their permissions to only what is necessary, reducing the attack surface.
Create a registry for all agent identities. This ensures you know what agents exist and how they interact with your systems.
Establish clear governance frameworks. Define accountability and approval processes for agent actions to enhance security.
Regularly review and rotate credentials. This practice helps maintain security and compliance by minimizing the risk of over-privileged accounts.
Stay informed about evolving threats and regulatory trends. Prepare your organization for the future of autonomous agents to protect against potential risks.

Why Stop Treating Agents as Service Accounts

You need to stop treating agents as service accounts if you want to protect your organization from modern threats. The old way of managing service accounts creates dangerous gaps in your security and governance. The M365 FM Podcast highlights how the rise of Shadow Agents exposes these weaknesses. You must recognize that ai agents bring new challenges that legacy identity and authorization models cannot handle.

Legacy Service Account Risks

Governance Blind Spots

Service account security risks often go unnoticed because traditional systems lack proper oversight. You may find that service accounts are created automatically by developers without a centralized tracking system. Each cloud platform uses different identity management practices, which leads to visibility issues. When you do not have a manager for each service account, accountability disappears. Non-human identities often operate outside governance frameworks, accumulating permissions without oversight. When a breach happens, you struggle to determine what these accounts accessed.

Tip: Centralized tracking and regular reviews can help you close these governance blind spots.

Accountability Gaps

You face serious accountability gaps when you rely on service accounts for agents. Legacy service accounts are often created without proper governance, which leads to unmonitored access. Static credentials and broad permissions make these accounts attractive to attackers. The lack of centralized management complicates the identification of responsible parties during a breach. You cannot easily trace actions back to a specific owner, which makes incident response slow and incomplete.

Service accounts lack human interaction, making them difficult to monitor.
Traditional security tools may fail to detect malicious activities.
Supply chain attacks often target service accounts for long-term, undetected access.

Agents’ Unique Challenges

Authority Inheritance

Agents introduce new risks that you cannot ignore. AI agents can inherit authority through complex delegation chains. This increases security risks if you do not manage them properly. Unlike service accounts, which operate with fixed roles and permissions, agents require you to monitor the lineage of authority, not just the last credential. If you misunderstand agents as either users or service accounts, you create operational and security problems.

AI agents are autonomous and can change tactics.
Governance of agents requires a new approach to authorization and identity.
You must track how authority passes from one agent to another.

Dynamic Decision-Making

AI agents do not behave like static service accounts. They adapt and change based on real-time context. This dynamic behavior means that traditional IAM controls fall short. Agents often require rapid provisioning and revocation of identities, which complicates management. You cannot rely on static credentials or fixed permissions. Instead, you need flexible authorization models that respond to the agent’s current context and tasks.

Agents often need more permissions than traditional service accounts, which increases the attack surface.
The need for rapid changes in identity and authorization makes manual processes impossible.
You must adopt risk-based governance to keep up with the pace of ai agent activity.

The M365 FM Podcast urges you to stop treating agents as service accounts. You must recognize the unique identity, authorization, and management needs of agents. By doing so, you close governance blind spots, eliminate accountability gaps, and reduce service account security risks. This shift prepares your organization for the future of autonomous agents and strengthens your overall IAM strategy.

Agents vs. Service Accounts

Identity Differences

Static vs. Dynamic

You need to understand the real difference between service accounts and agent identity. Service accounts work in a static way. They get created, assigned permissions, and rarely change. You set them up once and often forget about them. In contrast, agent identity is dynamic. Agents act based on real-time data and changing conditions. They make decisions, adapt to new information, and sometimes even change their own behavior. This difference in how they operate means you cannot use the same rules for both.

Here is a quick comparison to help you see the service account vs agent identity distinction:

	Service Accounts	Agent Identity
What they are	Digital credentials for systems or services	Task-driven intelligent systems powered by AI
Primary purpose	Enable machines or workloads to authenticate and access resources	Make decisions, act on data, and perform workflows
Security focus	Credential management, access controls, lifecycle	Behavior monitoring, permissions, and context limits
Identity lifecycle	Configured like a user account: created, rotated, expired	Not a standalone identity; built on top of service accounts
Risks	Exposed API keys, unused service accounts	Autonomous overreach, overprivileged, prompt injection, and misuse
Governance needs	Least privilege, credential hygiene, and rotation	Guardrails, explainability, and intent restriction
Identity security alignment	Enforce authentication, authorization, and visibility	Enforce action scope, verification, and observability

Contextual Awareness

Agents bring something new to the table: contextual awareness. This means agents can look at the situation, understand user intent, and decide if an action makes sense right now. Service accounts cannot do this. They only follow fixed rules. Agents, on the other hand, can adjust their actions based on who is asking, what data is involved, and what just happened. This makes agent identity much safer and smarter, but it also means you need new controls to keep things secure.

Lifecycle and Permissions

Over-Privileged Service Accounts

You face a big risk when you give service accounts too many permissions. Service accounts often get broad access because it is easier to set up. Over time, these permissions pile up. You may forget to remove them when they are no longer needed. This creates a huge attack surface. In the service account vs agent identity debate, agents can use context-aware permissions. These permissions change based on what the agent is doing and when. This reduces the risk of giving too much access.

Agents use permissions that adapt in real time, making it harder for attackers to exploit them.
Service accounts rely on static permissions, which can lead to excessive privileges.
Dynamic access lets you grant permissions only when needed, such as for a specific task or time window.
Conditional trust relationships help you shrink the impact if something goes wrong.

Credential Rotation

Managing the lifecycle of service accounts and agent identity requires different strategies. For service accounts, you need to assign a clear owner, track every stage from creation to retirement, and rotate credentials often. You should use short-lived credentials and revoke them automatically when not needed. Regularly review dormant accounts and unused keys. For agent identity, you must log every access decision and make sure you can explain why the agent still exists.

Assign a business or platform owner to every identity.
Track creation, purpose, usage, rotation, and retirement as separate events.
Prefer short-lived credentials and automatic revocation.
Review dormant identities and unused keys on a schedule.
Log enough context to prove why the identity is still active.

You cannot treat service accounts and agent identity the same way. The service account vs agent identity question is not just about technology. It is about security, governance, and the future of your organization. Agents need a distinct identity category because they act differently, require smarter controls, and demand better oversight. If you want to stay secure and compliant, you must adapt your approach now.

Risks of Over-Privileged Service Accounts

You cannot ignore the risks that come with over-privileged service accounts. These accounts open the door to major security threats, compliance failures, and unmanaged access. If you want to protect your organization, you must understand how attackers exploit these weaknesses and why you need to act now.

Lateral Movement Threats

Attackers love over-privileged service accounts because they offer easy ways to move through your systems. Once an attacker gets access to one of these accounts, they can use the credentials to reach other parts of your network. This is called lateral movement. You give attackers a map to your most valuable data when you allow over-permissioning.

Attackers can reuse compromised credentials to access adjacent systems.
Excessive permissions create pathways for attackers to pivot through databases and CI/CD platforms.
The lack of a clean revocation path lets attackers escalate privileges without raising alarms.
Service accounts often operate outside traditional security controls, making them prime targets.

You see this in real-world attacks. The attacker aims for durable access through legitimate machine identities. They move through your infrastructure, escalate privileges, and steal data without triggering alerts. Service accounts in Active Directory can increase security risks, especially in lateral movement attacks. These accounts often have high access privileges, which let attackers navigate the network and reach sensitive resources.

Alert: Approximately 74% of data breaches start with the misuse of privileged credentials, including over-privileged service accounts.

Audit and Compliance Issues

You face serious audit and compliance issues when you do not manage privileged accounts. Regulatory authorities demand strict controls over access to sensitive data. If you fail to comply, you risk heavy fines and legal trouble. Poorly managed privileged accounts create security threats. Unauthorized users can access and change confidential data if these accounts are compromised.

The risk of both internal and external breaches grows with weak controls. Malicious insiders or cybercriminals can exploit these accounts, leading to severe security incidents. You must keep a close eye on privileged accounts to meet compliance standards and protect your organization.

Shadow Agents and Unmanaged Access

Shadow Agents make unmanaged access a real danger. These agents operate without oversight and can access sensitive data on their own. They can break company policies and compliance rules. Without governance, Shadow Agents can misroute sensitive data or perform unauthorized actions.

A Fortune 500 financial services company found its customer service AI agent leaking account data for weeks after a prompt injection attack. This led to fines and high remediation costs.
Traders at a financial firm used an unauthorized AI tool to analyze market data, accessing sensitive customer information for months. This violated GLBA and SEC requirements.
In healthcare, staff used generic AI tools to analyze patient data without proper compliance, breaking HIPAA standards.

You cannot afford to let Shadow Agents run wild. You must put controls in place to stop unmanaged access and reduce security risks. The M365 FM Podcast highlights these real-world incidents to show why you need strong governance for agents and service accounts.

Agent Identity and Governance

You cannot secure your enterprise if you ignore the need for a third identity category. Traditional IAM systems only recognize users and service accounts. This leaves a gap for ai agents and agentic ai that act autonomously, make decisions, and interact with sensitive data. Treating these non-human identity types as service accounts creates security risks and compliance headaches. You need a new approach that gives agent identity its own blueprint, governance, and lifecycle.

Bar chart showing usage of different agent authentication methods by percentage

Look at the numbers. Almost half of organizations still use static API keys or share usernames and passwords for agent authentication. Only 18% feel confident in their current IAM for agent identities. This shows a clear need for a dedicated identity security model for agents.

“There are elements around agent identities, there’s elements around cataloging, there’s elements around centralizing policy and enforcing the right policies… one other key thing is context.”
— Senior architect, healthcare and insurance enterprise

Agent Identity Blueprints

You need a blueprint to manage agent identity at scale. A blueprint gives you a repeatable, secure way to create, manage, and retire agent identities. It ensures every agent follows the same rules and security controls. This approach helps you avoid the chaos of unmanaged non-human identity sprawl.

Here is what a strong agent identity blueprint includes:

Component	Description
Template	Records shared characteristics for consistent configuration across agent identities.
Identity	Acts as a special identity type that can provision or deprovision agent identities.
Credential container	Holds credentials used for authentication, enabling agent identities to request access tokens.
Management container	Allows application of policies and settings that affect all agent identities created from the blueprint.

You gain control and visibility by using these blueprints. You can enforce identity-based access, rotate credentials, and apply policies across all agents. This reduces the risks of orphaned or over-privileged agent identities. You also make it easier to audit and prove compliance.

Risk-Based Governance Models

You must move beyond static controls. Risk-based governance models let you adapt your security to the real-world behavior of ai agents. These models close the gap between legacy IAM and the needs of agentic ai. They give you the power to set guardrails based on the impact and context of each agent identity.

Legacy IAM systems cannot keep up with the speed and complexity of enterprise ai agents.
Agents now act as high-impact machine identities. They need robust governance controls that match their power and reach.
Traditional identity mechanisms rely on persistent credentials. These do not fit the transient, dynamic nature of agent identity.

With risk-based governance, you can monitor agent actions in real time. You can adjust permissions based on the current task, user, or data sensitivity. This approach strengthens your identity security and reduces the chance of unauthorized access. You also gain better control over non-human identity and agentic ai lifecycles.

Scoped and Ephemeral Access

You must limit what agents can do and for how long. Scoped and ephemeral access gives you this control. Instead of granting broad, permanent permissions, you give agents only the access they need, for the shortest time possible. This approach aligns with Zero Trust and modern identity-based access principles.

Short-lived credentials minimize exposure even if leaked.
Ephemeral access provides credentials that expire automatically, reducing the risk of compromise.
Dynamic scoping lets you grant permissions based on real-time context, so agents only get what they need for each task.
This method reduces standing privileges between tasks, shrinking the attack surface.
Ephemeral lifespans ensure that even if a credential is stolen, the damage is limited.

You protect your organization by using scoped and ephemeral access for all agent identities. You make it harder for attackers to exploit ai agents or non-human identity. You also improve your compliance posture and simplify audits.

You cannot afford to treat agents as an afterthought. By adopting agent identity blueprints, risk-based governance, and ephemeral access, you build a strong foundation for identity security. You prepare your enterprise for the future of agentic ai and reduce the risks that come with unmanaged agent identity.

Implementing Agent Identity Management

You can transform your organization’s security posture by implementing agent identity management with a clear, actionable approach. Start by building a strong foundation for registry and discovery, then enforce policies at runtime, and finally, monitor everything with robust audit trails.

Registry and Discovery

You need a reliable registry to track every agent identity. This step ensures you know exactly which agents exist, what they do, and how they interact with your systems. Follow these best practices to create a registry that supports auth for agents and strengthens your security:

Start small and iterate. Register a minimal set of agents and refine your process as you learn.
Use standard APIs for agent registration. This keeps your registry consistent and scalable.
Enable semantic search so agents can discover relevant tools and resources quickly.
Enforce governance from the beginning. Integrate authentication and single sign-on for every registry action.
Monitor and log all registry activity. Review logs regularly to spot unusual behavior.
Sync registry entries with your codebase using continuous integration.
Offer a user-friendly portal for easy agent exploration.
Leverage open-source frameworks to speed up development.

By following these steps, you gain visibility and control over agent identity, making it easier to enforce least-privilege policies and manage credential management.

Runtime Policy Enforcement

You must enforce policies while agents operate, not just after the fact. Runtime policy enforcement gives you real-time control over agent behavior and access. See how this approach compares to traditional service account controls:

Aspect	Runtime Policy Enforcement	Traditional Service Account Controls
Governance	Continuous governance of behavior	Post-activity auditing
Control Mechanism	Behavior containment during operation	Identity authentication and access granting
Adaptability	Designed for autonomous systems	Not built for real-time supervision of actions

Runtime governance focuses on containing agent actions as they happen. You need this because agents act autonomously and require continuous oversight. Traditional models only check identity and permissions at the start, missing risky behavior that happens later. With auth for agents, you can adapt policies in real time and ensure agents never exceed their intended authority.

Monitoring and Audit Trails

You cannot improve what you do not measure. Effective monitoring and audit trails give you the power to track every agent identity and credential. Build a comprehensive inventory and use access management tools to enforce least privilege. Replace persistent credentials with short-lived, task-scoped access to reduce risk. Implement joiner-mover-leaver workflows to manage the full lifecycle of agents and ensure accountability.

Regulations like SOC 2 and ISO 27001 require you to capture agent identity, timestamps, and decision context in tamper-resistant logs. These logs must be kept for years to support non-repudiation. Use network-level monitoring to see agent traffic and enforce attribution-linked policies, so every action traces back to a human principal.

Automate credential rotation and review permissions regularly. Attribute-based access control lets you evaluate permissions dynamically, keeping your environment secure. With strong monitoring, you close gaps in auth for agents and build trust in your identity program.

Tip: Automate credential management and permission reviews to stay ahead of threats and compliance demands.

Future of Agents in Enterprise

Evolving Threats

You face a new wave of threats as ai agents become more autonomous in your enterprise. Attackers now target these agents with tactics that go beyond traditional security models. You must understand the risks to stay ahead.

Threat Type	Description
Spoofing	Unauthorized access to systems by impersonating legitimate users.
Tampering	Alteration of data or systems by malicious actors.
Information Disclosure	Unauthorized access to sensitive information.
Denial of Service	Disruption of service availability to legitimate users.
Elevation of Privilege	Gaining higher access rights than authorized.
Advanced Threats	Unique vulnerabilities in GenAI agents, leading to novel attack vectors.

You cannot ignore these advanced threats. Compromised AI agents can manipulate your security tools to ignore real dangers. Unmonitored autonomous activity lets agents make critical changes without your knowledge. Autonomous policy bypass means an ai agent can redefine security policies, putting your compliance at risk. You also need to watch for instruction-data disconnects, where large language models confuse commands with user data. Memory poisoning can embed malicious instructions in an agent’s knowledge base, affecting future actions.

Stay alert: The attack surface grows as you deploy more ai agents. You must adapt your defenses to match.

Regulatory Trends

You must keep pace with fast-changing regulations. Governments now demand structured governance frameworks for AI agents. The ratio of humans to non-human identities keeps rising, which means you need stronger controls. The EU AI Act now requires risk management and transparency for high-risk AI systems. Non-compliance can cost you up to €35 million or 7% of your global revenue. In the United States, different states create unique compliance obligations, making governance even more complex.

By 2027, nearly every major economy will legally require agent governance.
You must prepare for mandatory audits and strict reporting standards.
Regulators expect you to prove that you control every agent and non-human identity in your environment.

Note: You cannot afford to wait. Start building your compliance strategy now to avoid costly penalties.

Preparing for Autonomous Agents

You need a plan to manage the rise of autonomous agents. Take these steps to secure your future:

Step	Description
Establish Governance Frameworks	Define accountability, approval processes, and ethical guidelines for agent actions.
Ensure Data Quality	Assess and improve data completeness, accuracy, and consistency across systems.
Define Organizational Roles	Assign agent owners with both business and technical knowledge to oversee performance.
Develop Integration Strategies	Map systems and data sources needed for agents, ensuring robust connectivity and access.
Implement Monitoring Processes	Establish metrics and alerts for ongoing evaluation of agent performance and integration.

You must act now. Build governance frameworks that define clear accountability. Assign owners who understand both business and technology. Improve your data quality to ensure agents make the right decisions. Map your systems and data sources so agents can operate safely. Set up monitoring and alerts to track agent performance and integration health.

Tip: Continuous governance and compliance are not optional. They are your best defense as agents become more autonomous.

You hold the power to shape the future of your enterprise. By adapting to evolving threats, meeting regulatory demands, and preparing for the next generation of autonomous agents, you protect your organization and unlock new opportunities.

You must stop treating agents as service accounts if you want to protect your organization from modern risks. AI agents operate with autonomy and speed, making traditional governance models obsolete. Most organizations lack policies for agent management, and agents will soon outnumber human identities. Adopt best practices like unique identification, least-privilege access, and continuous monitoring. The M365 FM Podcast offers insights to help you build a dynamic framework for agent identity management. Start now to secure your enterprise and stay ahead.

FAQ

What is the main risk of treating agents like service accounts?

You create security gaps. Agents act on their own and need unique controls. Service accounts cannot handle this. You risk data leaks, compliance failures, and attacks if you ignore agent-specific identity management.

How do agent identities differ from service accounts?

Agent identities change with context and tasks. Service accounts stay static. You need dynamic controls for agents. This keeps your environment secure and flexible.

Why should I use scoped and ephemeral access for agents?

Scoped and ephemeral access limits what agents can do and for how long. You reduce the attack surface. If credentials leak, the risk stays low. This approach supports Zero Trust and modern security.

How can I discover all agents in my environment?

Start with a registry. Register every agent as soon as you deploy it. Use APIs and automation to keep your list current. Regular reviews help you spot Shadow Agents.

What is a Shadow Agent?

A Shadow Agent is an unmanaged AI agent. You may not know it exists. It can access sensitive data without oversight. Shadow Agents create compliance and security risks.

How does agent identity management help with compliance?

Agent identity management gives you clear audit trails. You can show regulators who accessed what and when. This makes passing audits easier and avoids fines.

What first step should I take to improve agent governance?

Create a registry for all agents. Assign owners. Set up policies for access and monitoring. Start small, then expand. You build a strong foundation for security and compliance.

Where can I learn more about agent identity best practices?

Listen to the M365 FM Podcast. You get expert insights, real-world examples, and actionable steps. Stay ahead by learning from leaders in agent identity and governance.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:02,520
You think you're deploying AI, but in reality,

2
00:00:02,520 --> 00:00:04,440
you're deploying unmanaged identities.

3
00:00:04,440 --> 00:00:07,000
For the last 20 years, we solved identity in layers.

4
00:00:07,000 --> 00:00:09,720
First, we secured people, multi-factor authentication,

5
00:00:09,720 --> 00:00:12,200
conditional access, policies that verify who you are

6
00:00:12,200 --> 00:00:14,040
if you sign in from a new location.

7
00:00:14,040 --> 00:00:17,280
Then we secured apps, service principles, managed identities,

8
00:00:17,280 --> 00:00:19,920
credentials that let applications talk to databases

9
00:00:19,920 --> 00:00:21,360
without exposing secrets.

10
00:00:21,360 --> 00:00:22,200
We got good at this.

11
00:00:22,200 --> 00:00:24,680
We built the frameworks and automated the workflows,

12
00:00:24,680 --> 00:00:25,800
but we missed the layer.

13
00:00:25,800 --> 00:00:27,040
We missed the thing in the middle,

14
00:00:27,040 --> 00:00:29,280
the thing that acts like a person, but moves like an app.

15
00:00:29,280 --> 00:00:32,040
Now we have agents that can plan, decide, and chain actions

16
00:00:32,040 --> 00:00:33,680
across your entire environment.

17
00:00:33,680 --> 00:00:35,800
They read your email and browse your files.

18
00:00:35,800 --> 00:00:39,120
They update CRM records and escalate to humans when they get stuck.

19
00:00:39,120 --> 00:00:42,000
And we're still treating them like the workloads we built 20 years ago.

20
00:00:42,000 --> 00:00:43,400
That's where the system breaks.

21
00:00:43,400 --> 00:00:45,400
The old model worked because it was clean.

22
00:00:45,400 --> 00:00:47,680
Users had sessions, apps had credentials,

23
00:00:47,680 --> 00:00:49,960
everything flowed through a predictable channel.

24
00:00:49,960 --> 00:00:51,280
But agents don't fit that channel.

25
00:00:51,280 --> 00:00:52,520
They operate between the two.

26
00:00:52,520 --> 00:00:55,800
They act on behalf of users, but execute like applications.

27
00:00:55,800 --> 00:00:58,280
They make decisions on their own, but need oversight.

28
00:00:58,280 --> 00:01:00,800
They access multiple systems, but shouldn't touch everything.

29
00:01:00,800 --> 00:01:03,200
This isn't about a new feature or adding another checkbox

30
00:01:03,200 --> 00:01:04,640
in your security console.

31
00:01:04,640 --> 00:01:07,240
This is a shift in how identity actually works.

32
00:01:07,240 --> 00:01:09,960
Why service accounts were never built for agents?

33
00:01:09,960 --> 00:01:13,120
Service principles were designed for a world that no longer exists.

34
00:01:13,120 --> 00:01:14,480
When you build a service principle,

35
00:01:14,480 --> 00:01:17,880
you're answering a simple question, what does this app need to access?

36
00:01:17,880 --> 00:01:20,760
A web service that reads customer records needs the database.

37
00:01:20,760 --> 00:01:24,080
A background job that processes invoices needs the accounting system.

38
00:01:24,080 --> 00:01:25,080
The answer is static.

39
00:01:25,080 --> 00:01:25,880
It's deterministic.

40
00:01:25,880 --> 00:01:28,480
The script does one thing every single time.

41
00:01:28,480 --> 00:01:30,200
AI agents work differently.

42
00:01:30,200 --> 00:01:31,720
They don't execute a fixed script.

43
00:01:31,720 --> 00:01:33,520
They see a problem and decide how to solve it.

44
00:01:33,520 --> 00:01:36,520
They choose which tools to use and chain actions together.

45
00:01:36,520 --> 00:01:39,080
When they hit a situation outside their original design,

46
00:01:39,080 --> 00:01:40,680
they figure out what to do next.

47
00:01:40,680 --> 00:01:42,520
This is non-deterministic behavior.

48
00:01:42,520 --> 00:01:45,480
And your identity model has no vocabulary for it.

49
00:01:45,480 --> 00:01:49,680
Traditional R-back assumes a linear flow, identity to resource to permission.

50
00:01:49,680 --> 00:01:52,320
Does this service principle have read access to this database?

51
00:01:52,320 --> 00:01:53,000
Yes or no?

52
00:01:53,000 --> 00:01:54,400
It's a direct line.

53
00:01:54,400 --> 00:01:56,400
But agents don't operate in lines.

54
00:01:56,400 --> 00:01:57,480
They operate in networks.

55
00:01:57,480 --> 00:02:01,680
They access systems A and B, then decide they need to pull data from system C.

56
00:02:01,680 --> 00:02:05,360
They invoke one tool and the result tells them they need to call another.

57
00:02:05,360 --> 00:02:08,760
The relationship between the identity and the resources it touches is dynamic.

58
00:02:08,760 --> 00:02:10,040
So what happens in practice?

59
00:02:10,040 --> 00:02:12,000
You assign the agent a service principle.

60
00:02:12,000 --> 00:02:15,720
You know it might need to read email, access SharePoint, query HR,

61
00:02:15,720 --> 00:02:17,440
and create tasks and teams.

62
00:02:17,440 --> 00:02:19,800
You granted permissions for all of those things at once.

63
00:02:19,800 --> 00:02:21,880
You give it everything it might possibly need.

64
00:02:21,880 --> 00:02:23,840
Because if you don't, it will fail mid-process.

65
00:02:23,840 --> 00:02:24,920
And failure is expensive.

66
00:02:24,920 --> 00:02:25,960
Tasks don't get done.

67
00:02:25,960 --> 00:02:29,040
Users have to jump in and the whole point of automation collapses.

68
00:02:29,040 --> 00:02:31,400
You've created a God account, not because you wanted to,

69
00:02:31,400 --> 00:02:32,800
but because the alternative is worse.

70
00:02:32,800 --> 00:02:36,280
But that service principle now has access to broad swathes of your environment.

71
00:02:36,280 --> 00:02:37,640
And it's moving on its own.

72
00:02:37,640 --> 00:02:39,520
No human is watching every action.

73
00:02:39,520 --> 00:02:41,160
The agent decides what happens next.

74
00:02:41,160 --> 00:02:44,640
One compromise credential or one prompt injection attack is all it takes.

75
00:02:44,640 --> 00:02:48,240
One bug in the agent's reasoning and that blast radius expands across every system

76
00:02:48,240 --> 00:02:49,240
the agent can touch.

77
00:02:49,240 --> 00:02:50,880
This is the fundamental mismatch.

78
00:02:50,880 --> 00:02:54,840
Service principles were built for static, constrained workloads where you could predict

79
00:02:54,840 --> 00:02:56,360
every interaction in advance.

80
00:02:56,360 --> 00:02:59,880
Agents are dynamic adaptive systems that make decisions at runtime.

81
00:02:59,880 --> 00:03:04,880
Fourcing agents into the service principle model means you either accept huge security risks.

82
00:03:04,880 --> 00:03:07,800
Or you constrain the agent so much that it can't do its job.

83
00:03:07,800 --> 00:03:09,160
We need a different approach.

84
00:03:09,160 --> 00:03:12,120
One that treats agents as distinct from static workloads.

85
00:03:12,120 --> 00:03:15,560
One that lets you grant permissions based on what the agent is trying to do.

86
00:03:15,560 --> 00:03:16,680
And who asked it to do that?

87
00:03:16,680 --> 00:03:19,000
That's the structural shift we have to make.

88
00:03:19,000 --> 00:03:20,520
The shadow AI explosion.

89
00:03:20,520 --> 00:03:23,160
Here is what is happening inside your organization right now.

90
00:03:23,160 --> 00:03:25,600
The marketing team wants to summarize customer feedback.

91
00:03:25,600 --> 00:03:28,520
HR needs to process job applications faster.

92
00:03:28,520 --> 00:03:31,320
Finance wants to reconcile invoices without the manual work.

93
00:03:31,320 --> 00:03:35,000
Every team has a problem to solve and every team has the tools to do it.

94
00:03:35,000 --> 00:03:36,120
They have Copilot Studio.

95
00:03:36,120 --> 00:03:37,480
They have Azure AI Foundry.

96
00:03:37,480 --> 00:03:38,600
They have AWS Bedrock.

97
00:03:38,600 --> 00:03:39,800
So they build an agent.

98
00:03:39,800 --> 00:03:41,360
Nobody asks for permission.

99
00:03:41,360 --> 00:03:43,080
And nobody files a formal request.

100
00:03:43,080 --> 00:03:46,720
They don't go through a central approval process because that process does not even exist yet.

101
00:03:46,720 --> 00:03:49,880
The team simply builds the agent, connects it to the data and deploys it.

102
00:03:49,880 --> 00:03:52,520
The work gets done and the team moves on to the next task.

103
00:03:52,520 --> 00:03:58,120
But now you have an agent running in your environment that nobody in IT or security even knows is there.

104
00:03:58,120 --> 00:04:00,040
This isn't about people being malicious.

105
00:04:00,040 --> 00:04:04,000
It isn't a security breach or someone trying to bypass controls for a bad reason.

106
00:04:04,000 --> 00:04:06,440
This is just the reality of how work gets done today.

107
00:04:06,440 --> 00:04:09,120
Teams have problems and they use the tools available to solve them.

108
00:04:09,120 --> 00:04:12,120
We saw this with ShadowSas and we saw it with Shadow Infrastructure.

109
00:04:12,120 --> 00:04:14,120
Now we are seeing it with Shadow Agents.

110
00:04:14,120 --> 00:04:16,840
But the difference here is the scale and the invisibility.

111
00:04:16,840 --> 00:04:21,080
With ShadowSas, you can usually see the data leaving your network through basic monitoring.

112
00:04:21,080 --> 00:04:26,160
With Shadow Infrastructure, you can audit your cloud costs and see new resources appearing on the bill.

113
00:04:26,160 --> 00:04:27,560
But Shadow Agents are different.

114
00:04:27,560 --> 00:04:29,520
They run inside the systems you already own.

115
00:04:29,520 --> 00:04:31,200
They use the credentials you already issued.

116
00:04:31,200 --> 00:04:35,120
They operate within the networks and data pools you already approved from the outside.

117
00:04:35,120 --> 00:04:37,200
It just looks like normal application activity.

118
00:04:37,200 --> 00:04:40,760
The marketing agent uses a service account originally made for a different app.

119
00:04:40,760 --> 00:04:46,320
The HR agent uses graph API permissions that a developer requested months ago for a legitimate project.

120
00:04:46,320 --> 00:04:51,640
The finance agent gets into the accounting system because an admin granted access for a completely different integration.

121
00:04:51,640 --> 00:04:53,680
In the audit log, all of this looks authorized.

122
00:04:53,680 --> 00:04:55,200
It looks normal.

123
00:04:55,200 --> 00:04:58,240
But those credentials are being used for something they were never designed for.

124
00:04:58,240 --> 00:05:02,160
The permissions are being applied to use cases that nobody ever evaluated.

125
00:05:02,160 --> 00:05:04,160
Risks are being taken that nobody ever assessed.

126
00:05:04,160 --> 00:05:09,480
And when something goes wrong, when an agent touches data, it shouldn't or sends info to the wrong place.

127
00:05:09,480 --> 00:05:11,960
The first question is always, what happened?

128
00:05:11,960 --> 00:05:13,640
The answer in the audit log is useless.

129
00:05:13,640 --> 00:05:17,760
It says, a service principle accessed a resource at 3.47 pm.

130
00:05:17,760 --> 00:05:20,200
But it doesn't say which agent that was or who requested it.

131
00:05:20,200 --> 00:05:23,360
It doesn't tell you what it was trying to do or who authorized the action.

132
00:05:23,360 --> 00:05:26,240
The log was never designed to answer those questions.

133
00:05:26,240 --> 00:05:31,000
Research shows that 88% of organizations have already dealt with AI agent security failures.

134
00:05:31,000 --> 00:05:33,560
When you look at the root causes, the story is always the same.

135
00:05:33,560 --> 00:05:37,960
It is a mix of missing governance, identity misalignment, and runtime policy gaps.

136
00:05:37,960 --> 00:05:40,440
The agents themselves weren't necessarily unsafe.

137
00:05:40,440 --> 00:05:42,680
But nobody had visibility into what they were actually doing.

138
00:05:42,680 --> 00:05:44,200
This is the real cost of shadow AI.

139
00:05:44,200 --> 00:05:46,840
The problem isn't that it exists or that it is running.

140
00:05:46,840 --> 00:05:49,840
The real cost is that when it fails, you are blind.

141
00:05:49,840 --> 00:05:52,760
You cannot reconstruct the event or prove what was compromised.

142
00:05:52,760 --> 00:05:56,680
You cannot answer compliance questions because you don't actually understand the problem.

143
00:05:56,680 --> 00:06:00,200
The old governance model assumed you knew every identity in your environment.

144
00:06:00,200 --> 00:06:04,720
It assumed you controlled where they were created and had visibility into their actions.

145
00:06:04,720 --> 00:06:07,240
Agents broke all three of those assumptions.

146
00:06:07,240 --> 00:06:08,440
The identity vacuum.

147
00:06:08,440 --> 00:06:11,320
The deeper problem isn't just that these agents are invisible.

148
00:06:11,320 --> 00:06:15,600
It's that our identity systems were never designed to understand what an agent actually is.

149
00:06:15,600 --> 00:06:18,280
A service principle only answers one narrow question.

150
00:06:18,280 --> 00:06:20,240
It checks if a credential can access a resource.

151
00:06:20,240 --> 00:06:21,880
It is a simple binary check.

152
00:06:21,880 --> 00:06:26,080
The system does not know if that credential belongs to an AI agent or a standard legacy

153
00:06:26,080 --> 00:06:27,080
application.

154
00:06:27,080 --> 00:06:29,960
It doesn't know who built it, who owns it, or what its actual purpose is.

155
00:06:29,960 --> 00:06:33,320
It doesn't track if the agent is acting for a user or moving on its own.

156
00:06:33,320 --> 00:06:35,720
It doesn't know the data boundaries or the risk tier.

157
00:06:35,720 --> 00:06:39,480
This gap becomes a massive problem the moment you try to manage agent behavior in real

158
00:06:39,480 --> 00:06:41,160
time.

159
00:06:41,160 --> 00:06:43,160
A single conditional access was built for humans.

160
00:06:43,160 --> 00:06:44,440
The logic makes sense.

161
00:06:44,440 --> 00:06:48,760
If a user signs in from a new location or an un-patched device, you challenge them.

162
00:06:48,760 --> 00:06:51,600
This works because human behavior is predictable.

163
00:06:51,600 --> 00:06:54,840
Users have patterns that the system can recognize as normal or strange.

164
00:06:54,840 --> 00:06:59,560
But an agent accessing 1,000 files in 10 seconds isn't necessarily a red flag for an agent.

165
00:06:59,560 --> 00:07:01,760
That might be exactly what it was programmed to do.

166
00:07:01,760 --> 00:07:05,280
Quarering a warehouse and returning results in milliseconds isn't suspicious.

167
00:07:05,280 --> 00:07:06,760
It is just efficient.

168
00:07:06,760 --> 00:07:09,680
Conditional access has no way to tell the difference between a legitimate autonomous

169
00:07:09,680 --> 00:07:11,520
action and a compromise one.

170
00:07:11,520 --> 00:07:13,840
The system has no agent-specific risk signals.

171
00:07:13,840 --> 00:07:17,600
It cannot tell you if an agent is touching a new type of data for the first time.

172
00:07:17,600 --> 00:07:21,000
It doesn't know if today's request pattern matches the historical baseline.

173
00:07:21,000 --> 00:07:24,920
Identity protection builds profiles for users, but there is no equivalent for agents.

174
00:07:24,920 --> 00:07:28,920
The platform sees a token request and only checks if the role is correct.

175
00:07:28,920 --> 00:07:30,520
Everything else is silent.

176
00:07:30,520 --> 00:07:32,680
The audit trail reflects this lack of information.

177
00:07:32,680 --> 00:07:36,520
When an incident happens, the logger shows a service-principle ID and a timestamp.

178
00:07:36,520 --> 00:07:40,000
It doesn't tell you which team built the agent or what business process it was supporting.

179
00:07:40,000 --> 00:07:44,200
It doesn't show the data classification or if a human request triggered the move.

180
00:07:44,200 --> 00:07:47,680
The system recorded that a credential was used, but it didn't record the context.

181
00:07:47,680 --> 00:07:50,520
This turns incident response into a catastrophe.

182
00:07:50,520 --> 00:07:53,960
Security teams get an alert at 3am that sensitive data was accessed.

183
00:07:53,960 --> 00:07:56,240
They pull the logs and find the principle.

184
00:07:56,240 --> 00:07:59,160
But that credential might be shared across 10 different integrations.

185
00:07:59,160 --> 00:08:03,080
The team has to manually interview staff and hunt through code repositories just to figure

186
00:08:03,080 --> 00:08:04,080
out what happened.

187
00:08:04,080 --> 00:08:09,160
This process takes days or even weeks, the whole time, the organization is stuck in uncertainty.

188
00:08:09,160 --> 00:08:12,440
You don't know if data was stolen or just read, you don't know where it was sent.

189
00:08:12,440 --> 00:08:15,200
The visibility just isn't there to answer those questions quickly.

190
00:08:15,200 --> 00:08:16,720
The floor here is structural.

191
00:08:16,720 --> 00:08:20,520
Our identity systems were built for a world where humans started actions and applications

192
00:08:20,520 --> 00:08:21,680
finished them.

193
00:08:21,680 --> 00:08:23,880
Users logged in and applications ran jobs.

194
00:08:23,880 --> 00:08:26,640
Both were easy to categorize, but agents exist in the middle.

195
00:08:26,640 --> 00:08:30,040
They start actions like humans, but they execute like software.

196
00:08:30,040 --> 00:08:32,040
Traditional identity has no framework for this.

197
00:08:32,040 --> 00:08:36,320
It cannot express why an agent exists or if its behavior aligns with its purpose.

198
00:08:36,320 --> 00:08:39,960
That void is where the real governance failures happen.

199
00:08:39,960 --> 00:08:43,960
The cost of staying in the old model, you're operating in this state right now.

200
00:08:43,960 --> 00:08:47,800
Agents are running across your environment, some are known, many are not.

201
00:08:47,800 --> 00:08:51,760
The ones you do know about are running under service principles with broad permissions.

202
00:08:51,760 --> 00:08:53,960
Because nobody could figure out exactly what they'd need.

203
00:08:53,960 --> 00:08:57,440
The ones you don't know about are doing whatever they were built to do, with whatever access

204
00:08:57,440 --> 00:08:58,960
the creator decided to give them.

205
00:08:58,960 --> 00:09:00,160
What does this actually cost?

206
00:09:00,160 --> 00:09:03,560
It's not with the security side that overprivileged service principle is a target.

207
00:09:03,560 --> 00:09:06,240
It isn't malicious intent that creates the problem.

208
00:09:06,240 --> 00:09:07,240
It's inevitability.

209
00:09:07,240 --> 00:09:11,360
An attacker compromises an endpoint where that credential is stored, or they trick an employee

210
00:09:11,360 --> 00:09:16,160
into running a script that steals it, or they find it checked into a GitHub repository.

211
00:09:16,160 --> 00:09:19,640
The moment that credential is in an attacker's hands, they have access to everything that

212
00:09:19,640 --> 00:09:21,240
service principle can touch.

213
00:09:21,240 --> 00:09:24,560
They have the blast radius of an administrator without any of the controls.

214
00:09:24,560 --> 00:09:27,720
Because a God account has no restrictions, it can read your customer data.

215
00:09:27,720 --> 00:09:31,360
It can write to your financial systems that can delete your audit logs, and it does it all

216
00:09:31,360 --> 00:09:32,840
while the access looks legitimate.

217
00:09:32,840 --> 00:09:34,800
The cleanup doesn't take days, it takes months.

218
00:09:34,800 --> 00:09:37,800
You have to assume every system the principle touched was compromised.

219
00:09:37,800 --> 00:09:40,480
You have to rotate credentials for everything downstream.

220
00:09:40,480 --> 00:09:43,440
You have to audit six months of logs to see what was actually accessed.

221
00:09:43,440 --> 00:09:46,240
You have to notify customers if their data left your control.

222
00:09:46,240 --> 00:09:48,840
You have to brief your board on a security incident.

223
00:09:48,840 --> 00:09:52,800
The financial cost of a single breach of this nature runs into millions, but the daily

224
00:09:52,800 --> 00:09:55,200
cost is subtler and more pervasive.

225
00:09:55,200 --> 00:09:56,880
At scale you have hundreds of agents.

226
00:09:56,880 --> 00:09:58,880
There are probably thousands if you are a large organization.

227
00:09:58,880 --> 00:10:00,360
Each one needs permissions.

228
00:10:00,360 --> 00:10:02,640
Each one should follow least privilege in theory.

229
00:10:02,640 --> 00:10:07,280
But in practice, the process of determining exactly what permissions each agent needs is

230
00:10:07,280 --> 00:10:08,280
exhausting.

231
00:10:08,280 --> 00:10:10,240
So IT doesn't attempt it agent by agent.

232
00:10:10,240 --> 00:10:11,880
Instead they push back on the request.

233
00:10:11,880 --> 00:10:16,120
They tell the team building the agent that it needs to go through a formal governance process.

234
00:10:16,120 --> 00:10:17,120
That process takes weeks.

235
00:10:17,120 --> 00:10:19,680
The team gets frustrated that they build the agent anyway.

236
00:10:19,680 --> 00:10:22,880
Shadow AI again, because the official path is too slow.

237
00:10:22,880 --> 00:10:25,600
Or they settle for permissions that are too broad just to move forward.

238
00:10:25,600 --> 00:10:27,600
Either way, you're not scaling agents.

239
00:10:27,600 --> 00:10:29,480
You're suffocating them in bureaucracy.

240
00:10:29,480 --> 00:10:32,640
The security team meanwhile is drowning in incident response.

241
00:10:32,640 --> 00:10:34,240
Someone reports unusual activity.

242
00:10:34,240 --> 00:10:38,360
The team has to reconstruct what happened without good visibility into which agents exist,

243
00:10:38,360 --> 00:10:40,560
which teams own them or what they're supposed to be doing.

244
00:10:40,560 --> 00:10:42,080
They're not preventing incidents.

245
00:10:42,080 --> 00:10:45,600
They're responding to them after the fact that's expensive staff time that should be spent

246
00:10:45,600 --> 00:10:49,480
on strategy instead of being consumed by firefighting and compliance.

247
00:10:49,480 --> 00:10:52,040
Your compliance team is in an impossible position.

248
00:10:52,040 --> 00:10:56,320
In order to ask, which agents have accessed customer data in the last 90 days?

249
00:10:56,320 --> 00:10:57,520
The answer should be a query.

250
00:10:57,520 --> 00:10:59,320
Instead it's a month-long investigation.

251
00:10:59,320 --> 00:11:03,200
You have to manually contact teams, review logs, trace permissions, backwards, and hope

252
00:11:03,200 --> 00:11:04,360
you didn't miss anyone.

253
00:11:04,360 --> 00:11:07,840
You can't prove controls were in place because the controls aren't really there.

254
00:11:07,840 --> 00:11:09,200
Not in any structured sense.

255
00:11:09,200 --> 00:11:12,240
The best you can do is show that some people with access had it.

256
00:11:12,240 --> 00:11:14,000
But you can't prove they didn't misuse it.

257
00:11:14,000 --> 00:11:16,840
And you can't prove that unauthorized access was prevented.

258
00:11:16,840 --> 00:11:19,680
The compliance failure doesn't result in an incident you can point to.

259
00:11:19,680 --> 00:11:23,920
It results in failed audits, regulatory fines, customer contracts lost because you can't

260
00:11:23,920 --> 00:11:25,640
certify your controls.

261
00:11:25,640 --> 00:11:28,040
Insurance premiums that climb every quarter.

262
00:11:28,040 --> 00:11:31,880
Organizations that stay in the old model end up spending 40% more on identity governance

263
00:11:31,880 --> 00:11:32,960
than they should.

264
00:11:32,960 --> 00:11:37,000
Not because the technology is expensive, but because the model is fundamentally broken.

265
00:11:37,000 --> 00:11:40,600
You're trying to govern a system that was never designed to be governed this way.

266
00:11:40,600 --> 00:11:42,880
It's like trying to use a spreadsheet as a database.

267
00:11:42,880 --> 00:11:46,480
You can technically do it, but you spend all your time fighting the tool instead of solving

268
00:11:46,480 --> 00:11:47,480
the problem.

269
00:11:47,480 --> 00:11:49,920
Real opportunity cost is where it hurts most.

270
00:11:49,920 --> 00:11:53,480
You're not scaling AI adoption because you don't have the governance foundation.

271
00:11:53,480 --> 00:11:56,000
You know, agents could automate significant work.

272
00:11:56,000 --> 00:11:59,560
You know, they could unlock efficiency, but you can't approve them fast enough or govern

273
00:11:59,560 --> 00:12:02,360
them safely enough to deploy them at the scale where they matter.

274
00:12:02,360 --> 00:12:05,680
So the pilots stay pilots, the proof of concepts stay proof of concepts.

275
00:12:05,680 --> 00:12:09,360
The competitive advantage you could gain by automating your processes goes to organizations

276
00:12:09,360 --> 00:12:12,080
that figured out how to govern agents properly.

277
00:12:12,080 --> 00:12:15,920
This is where the model fundamentally breaks down.

278
00:12:15,920 --> 00:12:18,760
Why traditional identity models fail for agents?

279
00:12:18,760 --> 00:12:22,600
Let's be precise about what the traditional identity model actually does and why it collapses

280
00:12:22,600 --> 00:12:24,080
under agent workloads.

281
00:12:24,080 --> 00:12:26,720
Roll-based access control was built on a simple premise.

282
00:12:26,720 --> 00:12:29,200
You assign a user or application to a role.

283
00:12:29,200 --> 00:12:31,080
That role carries a fixed set of permissions.

284
00:12:31,080 --> 00:12:32,680
The administration is straightforward.

285
00:12:32,680 --> 00:12:36,800
A human resources administrator gets the HR role, which includes read-write access to

286
00:12:36,800 --> 00:12:37,800
employee records.

287
00:12:37,800 --> 00:12:41,800
A database service account gets the database reader role, which includes read-only access

288
00:12:41,800 --> 00:12:43,120
to specific tables.

289
00:12:43,120 --> 00:12:45,840
The permissions don't change unless you explicitly change them.

290
00:12:45,840 --> 00:12:46,960
The role is static.

291
00:12:46,960 --> 00:12:50,680
The person or service holding that role is expected to use those permissions in predictable

292
00:12:50,680 --> 00:12:51,680
consistent ways.

293
00:12:51,680 --> 00:12:53,520
This model works when behavior is predictable.

294
00:12:53,520 --> 00:12:54,520
It fails when it's not.

295
00:12:54,520 --> 00:12:56,960
An agent isn't assigned a role and then operates within it.

296
00:12:56,960 --> 00:12:58,520
An agent evaluates a problem.

297
00:12:58,520 --> 00:13:00,160
It decides what information it needs.

298
00:13:00,160 --> 00:13:02,560
It determines which systems can provide that information.

299
00:13:02,560 --> 00:13:03,800
It requests access.

300
00:13:03,800 --> 00:13:06,000
And it uses what it gets to make a decision.

301
00:13:06,000 --> 00:13:07,720
That decision informs the next action.

302
00:13:07,720 --> 00:13:10,720
That action might require access to a completely different system.

303
00:13:10,720 --> 00:13:12,200
The permission structure is dynamic.

304
00:13:12,200 --> 00:13:14,400
The intent behind each access is contextual.

305
00:13:14,400 --> 00:13:16,840
The role framework has no vocabulary for this.

306
00:13:16,840 --> 00:13:21,000
More fundamentally, the traditional model conflates several distinct pieces of information

307
00:13:21,000 --> 00:13:22,160
into a single credential.

308
00:13:22,160 --> 00:13:26,480
A service principle represents simultaneously the technology platform that's hosting the

309
00:13:26,480 --> 00:13:31,600
agent, the specific agent instance running on that platform, and the user or business context

310
00:13:31,600 --> 00:13:33,360
the agent is operating within.

311
00:13:33,360 --> 00:13:35,120
All three are baked into the same token.

312
00:13:35,120 --> 00:13:38,360
The system sees the token and makes a binary decision, yes or no.

313
00:13:38,360 --> 00:13:41,720
It never asks which of those three pieces is actually relevant to the question being

314
00:13:41,720 --> 00:13:43,040
asked.

315
00:13:43,040 --> 00:13:44,360
What are practical scenarios?

316
00:13:44,360 --> 00:13:48,560
An agent running in your Azure subscription makes a request to access a SharePoint site.

317
00:13:48,560 --> 00:13:50,360
The system checks.

318
00:13:50,360 --> 00:13:53,320
Does the service principle have read access to SharePoint?

319
00:13:53,320 --> 00:13:57,720
Yes, access granted, but the system never asked or answered.

320
00:13:57,720 --> 00:13:58,920
Several critical questions.

321
00:13:58,920 --> 00:14:01,640
Is this agent supposed to be accessing SharePoint at all?

322
00:14:01,640 --> 00:14:03,600
We know the platform can host agents?

323
00:14:03,600 --> 00:14:06,880
We know something that identifies as an agent is making the request.

324
00:14:06,880 --> 00:14:08,080
But is this the right agent?

325
00:14:08,080 --> 00:14:09,600
Is it acting in the right context?

326
00:14:09,600 --> 00:14:11,240
Is it accessing the right site?

327
00:14:11,240 --> 00:14:13,600
Should it be reading this particular type of data?

328
00:14:13,600 --> 00:14:18,280
Managed identities made this problem slightly better in Azure scenarios by eliminating secrets.

329
00:14:18,280 --> 00:14:19,880
But they didn't solve the core issue.

330
00:14:19,880 --> 00:14:21,360
They're still workload identities.

331
00:14:21,360 --> 00:14:25,440
They assume a one-to-one relationship between an identity and a resource or service.

332
00:14:25,440 --> 00:14:29,760
And as your function has a managed identity, that identity authenticates the function to downstream

333
00:14:29,760 --> 00:14:30,760
services.

334
00:14:30,760 --> 00:14:34,800
But when you have multiple agents running inside that function, or when the same agent needs

335
00:14:34,800 --> 00:14:37,640
to operate in different contexts, the model breaks again.

336
00:14:37,640 --> 00:14:39,680
You still can't distinguish between distinct agents.

337
00:14:39,680 --> 00:14:42,120
You still can't express contextual policy.

338
00:14:42,120 --> 00:14:44,200
The structural mismatch is this.

339
00:14:44,200 --> 00:14:47,400
Traditional identity models were designed for systems where you could predict behavior in

340
00:14:47,400 --> 00:14:48,400
advance.

341
00:14:48,400 --> 00:14:49,760
You knew what role a person would have.

342
00:14:49,760 --> 00:14:51,360
You knew what a service account would do.

343
00:14:51,360 --> 00:14:54,480
You could write policy based on those predictions.

344
00:14:54,480 --> 00:14:56,280
Conditional access logic works on this assumption.

345
00:14:56,280 --> 00:15:01,640
If the user is new, if the device is non-compliant, if the location is unfamiliar, then escalate.

346
00:15:01,640 --> 00:15:05,200
The system detects deviation from expected patterns and response.

347
00:15:05,200 --> 00:15:06,960
But agents don't have a predictable baseline.

348
00:15:06,960 --> 00:15:09,880
The first agent doesn't have a history to establish a baseline against.

349
00:15:09,880 --> 00:15:14,400
A new agent that behaves in ways the old agent never did isn't necessarily acting anomalously,

350
00:15:14,400 --> 00:15:16,200
it might be functioning exactly as intended.

351
00:15:16,200 --> 00:15:20,840
The policy framework has no way to distinguish intentional new behavior from compromised behavior.

352
00:15:20,840 --> 00:15:24,720
What you actually need from an identity system for agents goes far beyond yes or no access

353
00:15:24,720 --> 00:15:25,720
decisions.

354
00:15:25,720 --> 00:15:27,640
You need to know, what is this agent?

355
00:15:27,640 --> 00:15:28,640
Why was it created?

356
00:15:28,640 --> 00:15:30,080
Who is responsible for it?

357
00:15:30,080 --> 00:15:31,640
What type of data can it touch?

358
00:15:31,640 --> 00:15:33,800
What class of operation is it attempting?

359
00:15:33,800 --> 00:15:38,320
Need, right, execute, is it acting on behalf of a specific user or autonomously?

360
00:15:38,320 --> 00:15:41,520
Has anything about its behavior changed since it was approved?

361
00:15:41,520 --> 00:15:45,200
Does the action it's attempting align with the data boundaries we defined for this class

362
00:15:45,200 --> 00:15:46,200
of agent?

363
00:15:46,200 --> 00:15:48,680
Traditional identity models answer none of these questions.

364
00:15:48,680 --> 00:15:49,680
They were never designed to.

365
00:15:49,680 --> 00:15:53,760
And as long as you're forced to work within that framework, you're trying to govern agents

366
00:15:53,760 --> 00:15:57,960
with a system that has no comprehension of what agents actually are.

367
00:15:57,960 --> 00:16:00,640
The three identity types in the new model.

368
00:16:00,640 --> 00:16:03,560
For 20 years, enterprise identity was a binary world.

369
00:16:03,560 --> 00:16:07,880
You had users, humans with passwords and MFA who logged into apps to get work done.

370
00:16:07,880 --> 00:16:12,080
And you had workloads, the background services and code that talked to databases without any

371
00:16:12,080 --> 00:16:13,280
human involved.

372
00:16:13,280 --> 00:16:15,480
The entire system was built on this split.

373
00:16:15,480 --> 00:16:17,360
Users got conditional access.

374
00:16:17,360 --> 00:16:20,480
Workloads got service principles, two categories, two patterns.

375
00:16:20,480 --> 00:16:22,600
This model worked because it matched reality.

376
00:16:22,600 --> 00:16:23,760
A human started a task.

377
00:16:23,760 --> 00:16:24,760
The software finished it.

378
00:16:24,760 --> 00:16:26,640
It was clean and easy to govern.

379
00:16:26,640 --> 00:16:28,000
Agents break this model.

380
00:16:28,000 --> 00:16:29,000
They aren't users.

381
00:16:29,000 --> 00:16:31,560
They don't have a human lifespan or a desk in an office.

382
00:16:31,560 --> 00:16:35,920
An agent doesn't have a start date from HR or an off-boarding meeting when they quit.

383
00:16:35,920 --> 00:16:37,360
They don't sit in an org chart.

384
00:16:37,360 --> 00:16:40,600
They don't need MFA because they don't have a physical phone or human habits that hackers

385
00:16:40,600 --> 00:16:41,800
can exploit.

386
00:16:41,800 --> 00:16:42,960
But they aren't workloads either.

387
00:16:42,960 --> 00:16:44,360
A workload is static.

388
00:16:44,360 --> 00:16:46,360
It does the same thing every time it runs.

389
00:16:46,360 --> 00:16:48,080
A database account reads a table.

390
00:16:48,080 --> 00:16:49,960
An integration moves data from A to B.

391
00:16:49,960 --> 00:16:50,960
The scope is fixed.

392
00:16:50,960 --> 00:16:52,200
The behavior is predictable.

393
00:16:52,200 --> 00:16:53,360
An agent is different.

394
00:16:53,360 --> 00:16:54,480
It makes decisions.

395
00:16:54,480 --> 00:16:58,160
It looks at conditions and chains actions together based on what happens next.

396
00:16:58,160 --> 00:17:02,040
Its behavior depends on reasoning and input, not a pre-written script.

397
00:17:02,040 --> 00:17:06,400
So now your ecosystem has three distinct categories, users, workloads, agents.

398
00:17:06,400 --> 00:17:08,160
Each one has a different threat model.

399
00:17:08,160 --> 00:17:09,560
Users get fished.

400
00:17:09,560 --> 00:17:11,880
Workloads get their keys leaked in code.

401
00:17:11,880 --> 00:17:14,280
Agents face both of those plus a third.

402
00:17:14,280 --> 00:17:15,280
Gold hijacking.

403
00:17:15,280 --> 00:17:19,000
Someone can use a prompt to trick the agent into doing something it wasn't designed for.

404
00:17:19,000 --> 00:17:20,840
The agent's own logic becomes the weak point.

405
00:17:20,840 --> 00:17:22,320
They also act differently.

406
00:17:22,320 --> 00:17:23,800
Users work 9 to 5.

407
00:17:23,800 --> 00:17:25,440
Workloads run on a schedule you set.

408
00:17:25,440 --> 00:17:26,800
Agents work on demand.

409
00:17:26,800 --> 00:17:28,920
Feeling up and down whenever a request hits.

410
00:17:28,920 --> 00:17:31,360
They create a totally different type of audit trail.

411
00:17:31,360 --> 00:17:32,680
And they need different governance.

412
00:17:32,680 --> 00:17:34,400
HR manages users.

413
00:17:34,400 --> 00:17:37,480
Platform teams manage workloads through deployment pipelines.

414
00:17:37,480 --> 00:17:40,560
But agents are built by business teams on self-service platforms.

415
00:17:40,560 --> 00:17:42,120
They are deployed constantly.

416
00:17:42,120 --> 00:17:45,560
You have to validate them against business goals, not just technical specs.

417
00:17:45,560 --> 00:17:47,680
But here's the problem the old model couldn't solve.

418
00:17:47,680 --> 00:17:48,880
Who owns an agent?

419
00:17:48,880 --> 00:17:50,640
With a user, you look at their manager.

420
00:17:50,640 --> 00:17:52,560
With a workload, you look at the app team.

421
00:17:52,560 --> 00:17:56,160
But if a marketing team builds an agent in co-pilot studio that touches three different

422
00:17:56,160 --> 00:17:58,040
clouds, who is accountable?

423
00:17:58,040 --> 00:17:59,360
Who approves the permissions?

424
00:17:59,360 --> 00:18:01,360
Who investigates when it goes off the rails?

425
00:18:01,360 --> 00:18:03,000
This is why an agent ID exists.

426
00:18:03,000 --> 00:18:04,000
It isn't just a feature.

427
00:18:04,000 --> 00:18:05,640
It's a structural requirement.

428
00:18:05,640 --> 00:18:08,000
Agents are now first class identities in the directory.

429
00:18:08,000 --> 00:18:09,320
They get their own object ID.

430
00:18:09,320 --> 00:18:11,400
They get their own policies and life cycles.

431
00:18:11,400 --> 00:18:14,480
The audit logs show exactly what the agent did and why.

432
00:18:14,480 --> 00:18:16,040
You can govern them like users.

433
00:18:16,040 --> 00:18:20,240
With access reviews and risk scores, while they authenticate like workloads, that is the

434
00:18:20,240 --> 00:18:21,240
shift.

435
00:18:21,240 --> 00:18:23,120
We are moving from a binary model to a turner one.

436
00:18:23,120 --> 00:18:27,720
The blueprint hierarchy, Blueprints, principles, identities, users, so you have this third identity

437
00:18:27,720 --> 00:18:28,720
type.

438
00:18:28,720 --> 00:18:29,800
But how do you actually organize it?

439
00:18:29,800 --> 00:18:33,840
How do you stop every agent from becoming a snowflake that needs its own custom setup?

440
00:18:33,840 --> 00:18:35,240
The answer is hierarchy.

441
00:18:35,240 --> 00:18:36,480
The model isn't flat.

442
00:18:36,480 --> 00:18:37,880
It's built in four layers.

443
00:18:37,880 --> 00:18:41,280
And if you want to scale from five agents to five hundred, you have to understand how

444
00:18:41,280 --> 00:18:42,560
they fit together.

445
00:18:42,560 --> 00:18:45,480
It starts at the top with the agent identity blueprint.

446
00:18:45,480 --> 00:18:46,880
Think of this as the master template.

447
00:18:46,880 --> 00:18:48,560
You don't make a blueprint for every agent.

448
00:18:48,560 --> 00:18:49,920
You make them for types of agents.

449
00:18:49,920 --> 00:18:53,400
You have a blueprint for productivity agents that handle calendars and tasks.

450
00:18:53,400 --> 00:18:56,840
You have one for data agents that can read databases but never edit them.

451
00:18:56,840 --> 00:19:01,280
And you have one for transactional agents that can change records but only with human approval.

452
00:19:01,280 --> 00:19:02,760
The blueprint is where the policy lives.

453
00:19:02,760 --> 00:19:04,440
It decides which credentials can be used.

454
00:19:04,440 --> 00:19:06,240
It sets the permission baseline.

455
00:19:06,240 --> 00:19:09,560
What is allowed by default and what needs a manager to sign off.

456
00:19:09,560 --> 00:19:11,360
It even sets the expiration date.

457
00:19:11,360 --> 00:19:12,360
Blueprints are opinionated.

458
00:19:12,360 --> 00:19:13,360
That's the point.

459
00:19:13,360 --> 00:19:16,320
A high risk blueprint automatically blocks right operations.

460
00:19:16,320 --> 00:19:20,160
It forces the agent to use temporary permissions that vanish after the job is done.

461
00:19:20,160 --> 00:19:24,240
A low risk blueprint allows the agent to read internal docs without any extra hurdles.

462
00:19:24,240 --> 00:19:25,800
The power here is consistency.

463
00:19:25,800 --> 00:19:27,680
You define the policy once at the top.

464
00:19:27,680 --> 00:19:30,440
Every agent built from that template gets it automatically.

465
00:19:30,440 --> 00:19:34,360
If you need to tighten security, you update the blueprint and the change flows down to

466
00:19:34,360 --> 00:19:35,840
every agent using it.

467
00:19:35,840 --> 00:19:38,960
No more forgetting to update that one old agent running in the corner.

468
00:19:38,960 --> 00:19:40,880
The second layer is the blueprint principle.

469
00:19:40,880 --> 00:19:43,800
This is the version of the blueprint that lives in your specific tenant.

470
00:19:43,800 --> 00:19:47,360
The blueprint itself might be a global standard, but the principle is what actually issues

471
00:19:47,360 --> 00:19:48,360
the tokens.

472
00:19:48,360 --> 00:19:50,280
It's the engine that handles the authentication.

473
00:19:50,280 --> 00:19:52,840
It also owns the audit logs for every agent in that group.

474
00:19:52,840 --> 00:19:54,840
The third layer is the agent identity.

475
00:19:54,840 --> 00:19:56,080
This is the specific agent.

476
00:19:56,080 --> 00:19:58,040
It has its own ID in the directory.

477
00:19:58,040 --> 00:20:01,760
It inherits the rules from the blueprint, but it also has its own metadata.

478
00:20:01,760 --> 00:20:06,280
It has an owner, a human sponsor, and a live risk score based on what it's actually doing.

479
00:20:06,280 --> 00:20:07,960
The fourth layer is the agent user.

480
00:20:07,960 --> 00:20:09,880
This is a fallback for old systems.

481
00:20:09,880 --> 00:20:12,400
Some legacy apps don't understand what an agent is.

482
00:20:12,400 --> 00:20:16,960
They only want to see a user token, so you can link a user object to the agent identity

483
00:20:16,960 --> 00:20:18,560
for backward compatibility.

484
00:20:18,560 --> 00:20:19,560
Why build it this way?

485
00:20:19,560 --> 00:20:20,880
First, scale.

486
00:20:20,880 --> 00:20:23,000
One blueprint can support hundreds of agents.

487
00:20:23,000 --> 00:20:26,640
When a team builds something new, they don't start from zero, they pick a blueprint and

488
00:20:26,640 --> 00:20:28,400
the security is already handled.

489
00:20:28,400 --> 00:20:29,960
Second, governance.

490
00:20:29,960 --> 00:20:31,840
The blueprint is where the auditors look.

491
00:20:31,840 --> 00:20:33,720
Its version controlled and documented.

492
00:20:33,720 --> 00:20:35,960
Every policy decision is tracked at the source.

493
00:20:35,960 --> 00:20:37,400
Third, speed.

494
00:20:37,400 --> 00:20:40,440
This reduces the load on the people actually building the agents.

495
00:20:40,440 --> 00:20:42,160
They don't need to be security experts.

496
00:20:42,160 --> 00:20:45,080
They just pick the template that fits their use case and get to work.

497
00:20:45,080 --> 00:20:47,040
Human oversight moves to the blueprint layer.

498
00:20:47,040 --> 00:20:49,120
That's where you get the most leverage.

499
00:20:49,120 --> 00:20:50,640
Conditional access for agents.

500
00:20:50,640 --> 00:20:52,120
Not just users.

501
00:20:52,120 --> 00:20:53,640
Conditional access is a policy engine.

502
00:20:53,640 --> 00:20:56,000
It was built on a single inside-about risk.

503
00:20:56,000 --> 00:20:57,880
That not all access requests are equal.

504
00:20:57,880 --> 00:21:02,040
A user signing in from their desk on a company laptop during the day is low risk.

505
00:21:02,040 --> 00:21:06,560
But if that same user tries to sign in from a new country at 3am on an unmanaged device,

506
00:21:06,560 --> 00:21:07,720
the risk is high.

507
00:21:07,720 --> 00:21:11,360
The policy trusts the first scenario and demands more proof for the second.

508
00:21:11,360 --> 00:21:13,800
This logic changed everything for user security.

509
00:21:13,800 --> 00:21:17,720
We moved away from a simple yes or no model and started using context.

510
00:21:17,720 --> 00:21:20,960
The system looks at the risk profile in real time and decides what to do.

511
00:21:20,960 --> 00:21:22,920
If it's too risky, it asks for MFA.

512
00:21:22,920 --> 00:21:25,120
And if it's dangerous, it blocks the request entirely.

513
00:21:25,120 --> 00:21:28,240
Now, that same logic applies to agents, but the signals are different.

514
00:21:28,240 --> 00:21:30,320
A person has behaviors and an environment.

515
00:21:30,320 --> 00:21:33,000
You can track where they are or what device they use.

516
00:21:33,000 --> 00:21:35,800
An agent doesn't have a physical device or a home office.

517
00:21:35,800 --> 00:21:37,720
Its risk profile isn't about where it is.

518
00:21:37,720 --> 00:21:39,800
It's about what it's trying to do.

519
00:21:39,800 --> 00:21:43,280
An agent access for agents uses three new signals to make these decisions.

520
00:21:43,280 --> 00:21:45,280
First, agent risk.

521
00:21:45,280 --> 00:21:48,400
Identity protection now scores agents just like it scores people.

522
00:21:48,400 --> 00:21:51,600
It builds a baseline of what normal looks like for every agent.

523
00:21:51,600 --> 00:21:55,680
It tracks how often the agent asks for data, what kind of data it wants and how many requests

524
00:21:55,680 --> 00:21:56,880
it usually makes.

525
00:21:56,880 --> 00:22:01,240
When the agent starts acting weird, like suddenly grabbing thousands of files or touching data,

526
00:22:01,240 --> 00:22:02,520
it has never used before.

527
00:22:02,520 --> 00:22:03,720
The risk score goes up.

528
00:22:03,720 --> 00:22:07,280
A low risk agent stays trusted, but a high risk agent gets shut down.

529
00:22:07,280 --> 00:22:08,560
Second, action risk.

530
00:22:08,560 --> 00:22:10,240
This is where your policies get specific.

531
00:22:10,240 --> 00:22:12,640
The system doesn't just check if the agent has permission.

532
00:22:12,640 --> 00:22:14,680
It looks at the context of the action itself.

533
00:22:14,680 --> 00:22:19,040
Reading a file is one thing, but modifying it or deleting records is much riskier.

534
00:22:19,040 --> 00:22:24,160
Sending data to an external channel is a different level of threat than querying an internal database.

535
00:22:24,160 --> 00:22:27,880
You can write a policy that lets an agent read customer records on its own, but requires

536
00:22:27,880 --> 00:22:31,360
a human to click a proof before it can write or change anything.

537
00:22:31,360 --> 00:22:32,840
Third, context risk.

538
00:22:32,840 --> 00:22:35,720
The same action might be safe at noon, but dangerous at midnight.

539
00:22:35,720 --> 00:22:39,680
If an agent is working from a network, you control within a normal time window, the risk

540
00:22:39,680 --> 00:22:40,680
is low.

541
00:22:40,680 --> 00:22:44,200
But if that same request comes from an unvetted IP address or a runtime environment that

542
00:22:44,200 --> 00:22:47,480
lacks your security controls, the profile changes instantly.

543
00:22:47,480 --> 00:22:50,240
You can make this very tangible with concrete policies.

544
00:22:50,240 --> 00:22:54,800
You can tell the system to block every unverified agent by default so that only explicitly approved

545
00:22:54,800 --> 00:22:56,280
agents can even start.

546
00:22:56,280 --> 00:23:00,880
You can restrict, high-risk agents, so they only work on compliant networks.

547
00:23:00,880 --> 00:23:04,600
You can even set a rule that says any agent touching confidential data must have a human

548
00:23:04,600 --> 00:23:05,600
in the loop.

549
00:23:05,600 --> 00:23:08,160
You can't just read the file, it has to ask a person first.

550
00:23:08,160 --> 00:23:11,840
The most important part is that this enforcement happens at the identity layer.

551
00:23:11,840 --> 00:23:14,880
You don't have to patch the agent or change a single line of code.

552
00:23:14,880 --> 00:23:17,520
You don't have to revoke credentials and redeploy the whole thing.

553
00:23:17,520 --> 00:23:19,000
You just update the policy.

554
00:23:19,000 --> 00:23:22,440
The next time that agent tries to do something, the engine evaluates the request and stops

555
00:23:22,440 --> 00:23:24,200
it if it doesn't fit the rules.

556
00:23:24,200 --> 00:23:28,200
If an agent starts acting out, trying to scrape 10,000 files in 60 seconds or emailing

557
00:23:28,200 --> 00:23:30,480
an unknown address, the system catches it.

558
00:23:30,480 --> 00:23:31,720
The pattern is wrong.

559
00:23:31,720 --> 00:23:33,800
The action doesn't match the baseline.

560
00:23:33,800 --> 00:23:35,760
The signal access blocks it immediately.

561
00:23:35,760 --> 00:23:39,360
The damage is contained and you get an alert to start your investigation.

562
00:23:39,360 --> 00:23:42,840
This is policy enforcement at the speed of the modern threat environment.

563
00:23:42,840 --> 00:23:45,440
He agent registry, the single pane of glass.

564
00:23:45,440 --> 00:23:48,440
This is where the model hits the reality of how you actually work.

565
00:23:48,440 --> 00:23:51,720
In most companies, agents are running in five different places at once.

566
00:23:51,720 --> 00:23:55,280
Some are native to Azure, built in co-pilot studio or AI Foundry.

567
00:23:55,280 --> 00:23:58,680
Those are easy to see and manage because they live in your Microsoft environment.

568
00:23:58,680 --> 00:24:00,800
But then things get messy.

569
00:24:00,800 --> 00:24:05,680
They once built their own agents on AWS bedrock because they like the specific tools there,

570
00:24:05,680 --> 00:24:08,440
marketing went with Google Vertex for their own bottle choices.

571
00:24:08,440 --> 00:24:12,800
Your sales team is using agents inside Salesforce and your developers have custom frameworks running

572
00:24:12,800 --> 00:24:14,120
on their own servers.

573
00:24:14,120 --> 00:24:16,360
Every one of these platforms has its own way of tracking things.

574
00:24:16,360 --> 00:24:17,600
AWS has cloud trail.

575
00:24:17,600 --> 00:24:18,760
Google has its own logs.

576
00:24:18,760 --> 00:24:20,440
Salesforce keeps its own records.

577
00:24:20,440 --> 00:24:23,320
They are all capturing data but none of them are talking to each other.

578
00:24:23,320 --> 00:24:24,880
You end up with islands of information.

579
00:24:24,880 --> 00:24:28,920
You have fragmented visibility which means you can't answer the most basic question.

580
00:24:28,920 --> 00:24:30,960
How many agents do we actually have?

581
00:24:30,960 --> 00:24:33,280
This isn't just a theoretical problem for architects.

582
00:24:33,280 --> 00:24:36,600
It's a daily reality for any company with a hybrid cloud strategy.

583
00:24:36,600 --> 00:24:40,680
The agent in AWS can't see the one in Azure and your security policies in Entra don't

584
00:24:40,680 --> 00:24:42,440
mean anything to a bedrock agent.

585
00:24:42,440 --> 00:24:44,280
The result is a total failure of governance.

586
00:24:44,280 --> 00:24:47,440
You might manage each platform well on its own but you can't see the big picture.

587
00:24:47,440 --> 00:24:51,600
You can't spot patterns across clouds and you definitely can't enforce one consistent

588
00:24:51,600 --> 00:24:52,600
set of rules.

589
00:24:52,600 --> 00:24:54,280
This is why the agent registry exists.

590
00:24:54,280 --> 00:24:56,720
The registry is the Entra solution for this fragmentation.

591
00:24:56,720 --> 00:24:59,160
It doesn't replace the tools in AWS or Google.

592
00:24:59,160 --> 00:25:02,000
It sits on top of them as a central metadata store.

593
00:25:02,000 --> 00:25:05,400
It keeps track of every agent in your company no matter where it lives.

594
00:25:05,400 --> 00:25:10,080
It records the name, the purpose, the owner and the blueprint it's supposed to follow.

595
00:25:10,080 --> 00:25:13,840
It knows what data the agent touches and what its current risk score is.

596
00:25:13,840 --> 00:25:16,960
There is a new feature called registry sync that pulls all this together.

597
00:25:16,960 --> 00:25:21,400
You connect Entra to your AWS or Google environments and the sync process finds the agents living

598
00:25:21,400 --> 00:25:22,400
there.

599
00:25:22,400 --> 00:25:26,040
It pulls their details into Entra so you have one unified view of your entire ecosystem.

600
00:25:26,040 --> 00:25:27,280
And here's the shift.

601
00:25:27,280 --> 00:25:30,880
Once that AWS agent is in your Entra registry, it's no longer invisible.

602
00:25:30,880 --> 00:25:32,400
You can give it an Entra agent ID.

603
00:25:32,400 --> 00:25:34,600
You can apply your conditional access policies to it.

604
00:25:34,600 --> 00:25:38,520
You can put it through the same access reviews as your native Azure agents.

605
00:25:38,520 --> 00:25:40,000
The agent stays in AWS.

606
00:25:40,000 --> 00:25:43,240
It keeps using the same APIs and services it always did.

607
00:25:43,240 --> 00:25:49,600
But the governance, the rules and the audit trail now flow through one central place.

608
00:25:49,600 --> 00:25:54,760
This solves the problem of islands without forcing everyone to use the same platform.

609
00:25:54,760 --> 00:25:59,920
It's the most platform agent governance, the agent fabric, the agent registry solves visibility.

610
00:25:59,920 --> 00:26:03,200
You can see all your agents now, but seeing them is only the first step.

611
00:26:03,200 --> 00:26:08,360
The real question is, how do you govern them consistently when the infrastructure itself is fragmented?

612
00:26:08,360 --> 00:26:10,440
This is where the concept of the agent fabric enters.

613
00:26:10,440 --> 00:26:12,480
It isn't a product, it's a mental model.

614
00:26:12,480 --> 00:26:18,320
It's the framework for how governance actually works when agents exist across multiple clouds and platforms simultaneously.

615
00:26:18,320 --> 00:26:23,400
The agent fabric isn't about moving workloads, you aren't consolidating everything into one cloud.

616
00:26:23,400 --> 00:26:28,200
It's using bedrock because it fits their use case, marketing keeps using vertex for their reasons.

617
00:26:28,200 --> 00:26:31,240
And your native M365 co-pilot stay exactly where they are.

618
00:26:31,240 --> 00:26:33,040
The fabric sits above the infrastructure.

619
00:26:33,040 --> 00:26:36,960
It imposes uniform governance without requiring you to move a single piece of data.

620
00:26:36,960 --> 00:26:38,840
It operates in five distinct layers.

621
00:26:38,840 --> 00:26:40,360
The first layer is discovery.

622
00:26:40,360 --> 00:26:44,280
The agent registry syncs with your cloud platforms and finds agents wherever they happen to be running.

623
00:26:44,280 --> 00:26:45,720
But discovery is continuous.

624
00:26:45,720 --> 00:26:46,920
Not a one-time event.

625
00:26:46,920 --> 00:26:50,360
New agents are created constantly, some are built through official channels.

626
00:26:50,360 --> 00:26:55,480
While others are shadow agents that emerged without formal approval, the discovery process runs around the clock,

627
00:26:55,480 --> 00:26:58,960
identifying agents that haven't been registered yet and flagging them for triage.

628
00:26:58,960 --> 00:27:00,280
The second layer is identity.

629
00:27:00,280 --> 00:27:03,200
Every agent that's discovered gets an intra agent ID.

630
00:27:03,200 --> 00:27:06,000
That identity becomes the anchor point for everything else.

631
00:27:06,000 --> 00:27:08,880
The agent running on AWS now has an intra identity.

632
00:27:08,880 --> 00:27:11,560
The Salesforce automation now has an intra identity.

633
00:27:11,560 --> 00:27:14,320
And that identity isn't tied to where the agent runs.

634
00:27:14,320 --> 00:27:15,160
It's portable.

635
00:27:15,160 --> 00:27:20,160
It travels with the agent conceptually, creating a consistent governance identity across every platform

636
00:27:20,160 --> 00:27:21,160
you use.

637
00:27:21,160 --> 00:27:22,960
The third layer is policy.

638
00:27:22,960 --> 00:27:26,600
Conditional access and risk-based controls apply uniformly across the fabric.

639
00:27:26,600 --> 00:27:30,800
You write a policy that says agents accessing customer data must have human approval.

640
00:27:30,800 --> 00:27:35,320
That policy applies to the agent on AWS, the agent on Google, and the agent in Salesforce.

641
00:27:35,320 --> 00:27:38,240
You don't write AWS specific policies and Google specific policies.

642
00:27:38,240 --> 00:27:41,080
You write one policy that applies across the entire fabric.

643
00:27:41,080 --> 00:27:45,840
The enforcement happens through intra, and the agent's home platform doesn't even need to understand the policy.

644
00:27:45,840 --> 00:27:49,320
It just needs to respect the token decisions that intra makes.

645
00:27:49,320 --> 00:27:51,440
The fourth layer is observability.

646
00:27:51,440 --> 00:27:53,920
Logs flow from all your platforms into a central CM.

647
00:27:53,920 --> 00:27:58,520
AWS CloudTrail events, Azure Activity logs, and Salesforce audit logs all flow to a single

648
00:27:58,520 --> 00:27:59,520
place.

649
00:27:59,520 --> 00:28:01,560
The logs are correlated and analyzed together.

650
00:28:01,560 --> 00:28:05,640
You can track an agent action that spans multiple platforms, seeing the complete sequence

651
00:28:05,640 --> 00:28:07,640
of what happened in chronological order.

652
00:28:07,640 --> 00:28:10,760
The audit trail is unified even though the platforms are separate.

653
00:28:10,760 --> 00:28:12,440
The fifth layer is life cycle.

654
00:28:12,440 --> 00:28:16,120
Agents are created, reviewed, and decommissioned through a unified process.

655
00:28:16,120 --> 00:28:19,440
You don't have separate workflows for AWS agents and Azure agents.

656
00:28:19,440 --> 00:28:22,960
You have one process that applies to all agents, regardless of where they run.

657
00:28:22,960 --> 00:28:27,080
An agent created in Bedrock goes through the same approval workflow as an agent in Copilot

658
00:28:27,080 --> 00:28:29,360
Studio when an agent needs to be retired.

659
00:28:29,360 --> 00:28:33,560
A single decommissioning process removes it from the registry and communicates that retirement

660
00:28:33,560 --> 00:28:34,720
across all platforms.

661
00:28:34,720 --> 00:28:36,200
The benefit is profound.

662
00:28:36,200 --> 00:28:39,960
You can answer questions that are impossible to answer in a fragmented environment.

663
00:28:39,960 --> 00:28:43,400
Which agents have accessed customer data in the last 90 days?

664
00:28:43,400 --> 00:28:45,920
You query the unified registry and audit trail.

665
00:28:45,920 --> 00:28:49,480
When you get an answer, if an agent is compromised, what's the blast radius?

666
00:28:49,480 --> 00:28:53,520
You look at its permissions across all platforms and see everywhere it could have caused damage.

667
00:28:53,520 --> 00:28:54,640
Is this agent still in use?

668
00:28:54,640 --> 00:28:56,400
You check its activity across all systems.

669
00:28:56,400 --> 00:28:57,520
Can we decommission it?

670
00:28:57,520 --> 00:29:00,120
You trace all its dependencies across the fabric.

671
00:29:00,120 --> 00:29:03,360
But getting there requires a fundamental shift in thinking.

672
00:29:03,360 --> 00:29:05,920
Governance is no longer the responsibility of individual platforms.

673
00:29:05,920 --> 00:29:07,880
AWS doesn't govern the Bedrock agent.

674
00:29:07,880 --> 00:29:09,600
Google doesn't govern the vertex agent.

675
00:29:09,600 --> 00:29:10,600
Entra does.

676
00:29:10,600 --> 00:29:13,920
Its organizational governance imposed on infrastructure, not infrastructure governance

677
00:29:13,920 --> 00:29:15,560
delegated to platforms.

678
00:29:15,560 --> 00:29:16,680
This requires coordination.

679
00:29:16,680 --> 00:29:20,760
It requires buy-in from security, from cloud teams and from compliance.

680
00:29:20,760 --> 00:29:24,880
It requires treating identity as the control plane that sits above the infrastructure,

681
00:29:24,880 --> 00:29:27,040
not as a property of individual systems.

682
00:29:27,040 --> 00:29:31,080
That coordination is what the next phase actually operationalizes.

683
00:29:31,080 --> 00:29:34,040
Leased privilege orchestration, the blueprint in action.

684
00:29:34,040 --> 00:29:37,000
Understanding the theory of least privilege is one thing, implementing it in practice is

685
00:29:37,000 --> 00:29:38,000
another.

686
00:29:38,000 --> 00:29:40,600
The challenge with agents is that they aren't static workloads.

687
00:29:40,600 --> 00:29:44,840
You can't simply say, this agent needs read access to this database and be done.

688
00:29:44,840 --> 00:29:48,480
An agent might need to read from a database, but it might also need to create a task, send

689
00:29:48,480 --> 00:29:50,480
a notification and update a record.

690
00:29:50,480 --> 00:29:54,080
Those operations might be necessary, but only in specific sequences, granting everything

691
00:29:54,080 --> 00:29:59,160
upfront creates risk, trying to gatekeep every edge case becomes administratively suffocating.

692
00:29:59,160 --> 00:30:03,360
The blueprint approach solves this by encoding permission logic at the template level.

693
00:30:03,360 --> 00:30:04,960
Here's how it actually works.

694
00:30:04,960 --> 00:30:05,960
Start with definition.

695
00:30:05,960 --> 00:30:09,760
You're designing a blueprint for an HR agent that handles new hire on boarding.

696
00:30:09,760 --> 00:30:11,240
Its purpose is narrow.

697
00:30:11,240 --> 00:30:16,120
First information, creator checklist, schedule orientation and assign initial tasks.

698
00:30:16,120 --> 00:30:17,120
That's it.

699
00:30:17,120 --> 00:30:20,120
You aren't asking the agent to process payroll or modify benefits.

700
00:30:20,120 --> 00:30:21,920
That focus matters.

701
00:30:21,920 --> 00:30:24,640
Everything the agent needs follows from that single purpose.

702
00:30:24,640 --> 00:30:26,640
Now you translate purpose into permissions.

703
00:30:26,640 --> 00:30:29,040
The agent needs to read from your HR system.

704
00:30:29,040 --> 00:30:33,480
And it needs right access to a specific sharepoint site where on boarding documents live, it

705
00:30:33,480 --> 00:30:35,760
needs permission to create tasks in teams.

706
00:30:35,760 --> 00:30:39,680
That's the legitimate scope, not all of SharePoint, but this specific site, not all teams

707
00:30:39,680 --> 00:30:42,040
tasks, but this specific team's channel.

708
00:30:42,040 --> 00:30:44,240
You document restrictions explicitly.

709
00:30:44,240 --> 00:30:48,320
The agent cannot read from other department's data, it cannot modify payroll information,

710
00:30:48,320 --> 00:30:49,880
it cannot access email.

711
00:30:49,880 --> 00:30:51,280
These aren't just recommendations.

712
00:30:51,280 --> 00:30:53,160
They're enforced at the identity layer.

713
00:30:53,160 --> 00:30:57,480
The agent's token, issued by the blueprint principle, has these boundaries baked in.

714
00:30:57,480 --> 00:31:01,080
Even if someone wrote code in the agent that tried to access forbidden data, the token

715
00:31:01,080 --> 00:31:02,080
wouldn't authorize it.

716
00:31:02,080 --> 00:31:03,720
The platform would reject the request.

717
00:31:03,720 --> 00:31:05,200
Then you handle the gray areas.

718
00:31:05,200 --> 00:31:08,360
What if the agent encounters a situation outside its design?

719
00:31:08,360 --> 00:31:10,240
A new hire with special accommodations?

720
00:31:10,240 --> 00:31:11,800
Or a complex background check issue?

721
00:31:11,800 --> 00:31:13,960
The agent shouldn't make autonomous decisions here.

722
00:31:13,960 --> 00:31:14,960
It should escalate.

723
00:31:14,960 --> 00:31:17,560
You build approval workflows into the agent's logic.

724
00:31:17,560 --> 00:31:19,960
But you also enforce them at the policy layer.

725
00:31:19,960 --> 00:31:24,160
If the agent tries to proceed without getting human approval, conditional access blocks it,

726
00:31:24,160 --> 00:31:25,760
the agent can't force its way through.

727
00:31:25,760 --> 00:31:28,760
The actual enforcement happens through a combination of mechanisms.

728
00:31:28,760 --> 00:31:31,760
The blueprint principles token include scoped credentials.

729
00:31:31,760 --> 00:31:35,680
They have limited scope and can only be used for specific graph API calls.

730
00:31:35,680 --> 00:31:38,320
The Azure road assignments for the agent are restrictive.

731
00:31:38,320 --> 00:31:42,440
The conditional access policy attached to this blueprint says, any right operation to payroll

732
00:31:42,440 --> 00:31:43,840
systems is blocked.

733
00:31:43,840 --> 00:31:45,600
Any external data export is blocked.

734
00:31:45,600 --> 00:31:48,160
Any action outside the approved teams channel is blocked.

735
00:31:48,160 --> 00:31:51,080
These controls operate independently if one fails.

736
00:31:51,080 --> 00:31:52,520
The others catch the violation.

737
00:31:52,520 --> 00:31:53,960
Here's the operational advantage.

738
00:31:53,960 --> 00:31:55,640
You can scale this safely.

739
00:31:55,640 --> 00:31:59,040
You design one blueprint for this category of HR agents.

740
00:31:59,040 --> 00:32:03,440
Every HR agent created from that blueprint inherits the same permission boundaries, the

741
00:32:03,440 --> 00:32:05,880
same restrictions and the same approval workflows.

742
00:32:05,880 --> 00:32:08,240
When you onboard a new HR team, they don't need custom

743
00:32:08,240 --> 00:32:09,240
governance.

744
00:32:09,240 --> 00:32:10,400
They use the existing blueprint.

745
00:32:10,400 --> 00:32:13,160
The controls are already there when policy needs to change.

746
00:32:13,160 --> 00:32:14,400
You update the blueprint.

747
00:32:14,400 --> 00:32:16,280
Every agent using it inherits the change.

748
00:32:16,280 --> 00:32:19,240
No per agent configuration, no drift.

749
00:32:19,240 --> 00:32:20,800
The blast radius is contained.

750
00:32:20,800 --> 00:32:24,000
If an HR agent is compromised, its access is already constrained.

751
00:32:24,000 --> 00:32:28,000
It can't exfiltrate payroll data because it doesn't have access to payroll systems.

752
00:32:28,000 --> 00:32:32,280
It can't modify customer records because it doesn't have permissions outside the HR domain.

753
00:32:32,280 --> 00:32:35,800
The damage it can do is proportional to the permissions it actually holds.

754
00:32:35,800 --> 00:32:39,280
What the permissions you granted it because you couldn't figure out exactly what it needed?

755
00:32:39,280 --> 00:32:42,640
This is how you scale agents safely.

756
00:32:42,640 --> 00:32:44,880
Observability and attribution who did what and why?

757
00:32:44,880 --> 00:32:49,380
You have designed the policies, created the blueprints and enforced the controls, but enforcement

758
00:32:49,380 --> 00:32:50,460
is only half the story.

759
00:32:50,460 --> 00:32:53,040
The other half is knowing what actually happened.

760
00:32:53,040 --> 00:32:57,300
Traditional logging gave you a bare fact like telling you that service principle x accessed

761
00:32:57,300 --> 00:33:01,000
resource y at 10 am and that was the extent of the information.

762
00:33:01,000 --> 00:33:04,640
If something went wrong, you had to manually investigate by finding which application used

763
00:33:04,640 --> 00:33:08,580
that service principle and interviewing people about why it accessed that resource.

764
00:33:08,580 --> 00:33:12,820
You had to reconstruct context that the log itself never captured, which often meant the

765
00:33:12,820 --> 00:33:15,720
most important details stayed trapped in someone's head.

766
00:33:15,720 --> 00:33:19,200
The new logging model is qualitatively different because it provides a complete narrative of

767
00:33:19,200 --> 00:33:20,200
the event.

768
00:33:20,200 --> 00:33:25,240
Agent A owned by team B and acting on behalf of user C accessed file d at 10 am to perform

769
00:33:25,240 --> 00:33:26,480
a read operation.

770
00:33:26,480 --> 00:33:30,440
The result was success, the risk score was low, and everything you need to understand

771
00:33:30,440 --> 00:33:32,360
the situation is right there in the record.

772
00:33:32,360 --> 00:33:36,520
This data isn't scattered across multiple systems or hidden in a human's memory, but lives

773
00:33:36,520 --> 00:33:38,640
directly in the audit trail itself.

774
00:33:38,640 --> 00:33:43,160
The log captures four distinct elements working together to provide total visibility.

775
00:33:43,160 --> 00:33:48,160
Agent signin logs record the moment of authentication, showing when the agent signed in and which

776
00:33:48,160 --> 00:33:49,600
network it used.

777
00:33:49,600 --> 00:33:54,120
It verifies if the token was issued by the expected blueprint principle and checks if the risk

778
00:33:54,120 --> 00:33:56,160
score was within the expected range.

779
00:33:56,160 --> 00:33:59,400
These are the foundational questions that tell you whether the agent's very presence in

780
00:33:59,400 --> 00:34:01,080
the system was legitimate.

781
00:34:01,080 --> 00:34:04,880
Agent logs record what the agent actually did, moving beyond a simple note that access

782
00:34:04,880 --> 00:34:07,080
occurred to show specific operations.

783
00:34:07,080 --> 00:34:12,400
It logs whether the agent read a file, created a task, updated a record or queried a database.

784
00:34:12,400 --> 00:34:15,440
Each action is recorded individually with its parameters and results.

785
00:34:15,440 --> 00:34:19,960
So if an agent reads a file, the log captures which file it was and how much data was transferred.

786
00:34:19,960 --> 00:34:24,400
If it updated a record, the log captures the before and after states so you can see exactly

787
00:34:24,400 --> 00:34:25,400
what changed.

788
00:34:25,400 --> 00:34:29,520
Audit logs record who approved what and when, which is vital if the action required a

789
00:34:29,520 --> 00:34:30,600
human sign off.

790
00:34:30,600 --> 00:34:34,480
If the agent hit an approval workflow, the log captures which human approved it when they

791
00:34:34,480 --> 00:34:37,440
did it and what context they saw when they made that decision.

792
00:34:37,440 --> 00:34:41,600
If the action was blocked by conditional access, the log captures that too, showing you exactly

793
00:34:41,600 --> 00:34:45,320
why it was blocked and which specific policy triggered that stop.

794
00:34:45,320 --> 00:34:49,480
Risk logs overlay behavioral analysis on top of these operational records to see if the

795
00:34:49,480 --> 00:34:51,000
access was anomalous.

796
00:34:51,000 --> 00:34:55,880
It asks if the behavior deviated from the agent's normal pattern or if the action was consistent

797
00:34:55,880 --> 00:34:58,080
with the intended purpose of its blueprint.

798
00:34:58,080 --> 00:35:01,840
The risk assessment isn't a separate process running in a black box but is recorded in the

799
00:35:01,840 --> 00:35:06,320
audit trail so you can see how the system evaluated the situation in real time.

800
00:35:06,320 --> 00:35:11,000
Consider a real scenario where an agent starts exfiltrating files to an external email address.

801
00:35:11,000 --> 00:35:15,320
The moment it attempts this, the system recognizes it as anomalous because the agent has never

802
00:35:15,320 --> 00:35:17,240
contacted this email address before.

803
00:35:17,240 --> 00:35:21,960
The action of sending customer data to an external email is flagged by DLP as a high risk operation

804
00:35:21,960 --> 00:35:25,800
and conditional access evaluates the context and decides to block it.

805
00:35:25,800 --> 00:35:29,960
The agent cannot complete the exfiltration and the audit trail captures the entire sequence

806
00:35:29,960 --> 00:35:31,240
from start to finish.

807
00:35:31,240 --> 00:35:34,880
You can see the agent's normal activity leading up to the attempt and the exact moment the

808
00:35:34,880 --> 00:35:36,040
anomaly was detected.

809
00:35:36,040 --> 00:35:39,760
You can see which policy triggered the block and at what point the action failed, allowing

810
00:35:39,760 --> 00:35:42,560
you to reconstruct exactly what the agent tried to do.

811
00:35:42,560 --> 00:35:46,000
For compliance teams this is transformative because they no longer have to launch a massive

812
00:35:46,000 --> 00:35:50,960
investigation when a regulator asks which agent's access customer data.

813
00:35:50,960 --> 00:35:55,120
Instead of guessing you run a query against the audit trail and get a structured answer.

814
00:35:55,120 --> 00:35:59,600
With ex access customer data on these dates it was owned by TMY and here is the audit evidence

815
00:35:59,600 --> 00:36:00,760
showing what it did.

816
00:36:00,760 --> 00:36:04,600
You can prove that controls were in place and enforced with actual evidence rather than

817
00:36:04,600 --> 00:36:06,000
a best effort guess.

818
00:36:06,000 --> 00:36:10,320
For operations teams these same logs enable continuous improvement by showing which agents

819
00:36:10,320 --> 00:36:13,000
are used regularly and which haven't been touched in months.

820
00:36:13,000 --> 00:36:16,640
You can make data driven decisions about which agents are valuable and which are candidates

821
00:36:16,640 --> 00:36:17,640
for retirement.

822
00:36:17,640 --> 00:36:21,080
You see which ones trigger the most exceptions which tells you something about their design

823
00:36:21,080 --> 00:36:24,840
and you can spot behavioral drift before it becomes a real problem.

824
00:36:24,840 --> 00:36:27,360
Using agent blueprints from theory to practice.

825
00:36:27,360 --> 00:36:31,320
Now you understand what the control plane does, how conditional access enforces policy and

826
00:36:31,320 --> 00:36:35,280
how the registry provides visibility but where does the policy itself come from and who

827
00:36:35,280 --> 00:36:37,760
decides what agents can and cannot do.

828
00:36:37,760 --> 00:36:41,400
You have to translate an abstract framework into something concrete that actually works and

829
00:36:41,400 --> 00:36:43,960
this is where blueprints move from concept to practice.

830
00:36:43,960 --> 00:36:48,280
A blueprint isn't a feature but a governance artifact that represents a structured decision

831
00:36:48,280 --> 00:36:50,840
about what a category of agents is allowed to do.

832
00:36:50,840 --> 00:36:55,760
It defines how their permissions are scoped and what controls apply to them, encoding organizational

833
00:36:55,760 --> 00:36:58,400
policy directly into the identity system.

834
00:36:58,400 --> 00:37:02,640
This replaces the old model of relying on manual processes or just hoping that teams will

835
00:37:02,640 --> 00:37:04,000
follow the guidelines.

836
00:37:04,000 --> 00:37:07,080
Think of building a blueprint as answering a series of specific questions about what the

837
00:37:07,080 --> 00:37:08,240
agent is supposed to do.

838
00:37:08,240 --> 00:37:11,800
You need to define this in concrete operational terms rather than marketing language.

839
00:37:11,800 --> 00:37:16,640
An IT support agent triages tickets, gathers diagnostic information and suggest solutions

840
00:37:16,640 --> 00:37:18,720
and that is its entire scope.

841
00:37:18,720 --> 00:37:23,400
When you authorize flows from that single definition and everything outside that scope is restricted,

842
00:37:23,400 --> 00:37:28,040
the blueprint captures this in five distinct dimensions starting with identity which covers

843
00:37:28,040 --> 00:37:29,480
how the agent authenticates.

844
00:37:29,480 --> 00:37:34,360
It tracks whether the agent uses a managed identity, a federated credential or a certificate

845
00:37:34,360 --> 00:37:36,640
focusing on the token issuance mechanism.

846
00:37:36,640 --> 00:37:40,440
This ensures the agent's credential can be rotated automatically rather than requiring

847
00:37:40,440 --> 00:37:42,160
manual intervention.

848
00:37:42,160 --> 00:37:45,760
Permissions then define exactly what the agent can touch such as whether it can read

849
00:37:45,760 --> 00:37:49,400
from one specific SharePoint site or the entire environment.

850
00:37:49,400 --> 00:37:52,840
Policies define the controls that wrap around those permissions including conditional access

851
00:37:52,840 --> 00:37:56,080
logic, DLP rules and approval workflows.

852
00:37:56,080 --> 00:37:59,800
These aren't decided for every individual agent but are set at the blueprint level and

853
00:37:59,800 --> 00:38:01,600
inherited automatically.

854
00:38:01,600 --> 00:38:05,400
Life cycle rules specify how the agent evolves over time, determining when it should be

855
00:38:05,400 --> 00:38:08,240
reviewed and if approval needs to be renewed quarterly.

856
00:38:08,240 --> 00:38:13,600
It also sets the maximum lifespan and determines what triggers the agent to be disabled automatically.

857
00:38:13,600 --> 00:38:18,120
This data captures the contextual information that makes governance possible by identifying

858
00:38:18,120 --> 00:38:22,160
who owns the blueprint and what risk tier it falls under.

859
00:38:22,160 --> 00:38:26,120
This metadata is searchable and queryable which is how you answer questions about which

860
00:38:26,120 --> 00:38:28,920
agents can access customer data.

861
00:38:28,920 --> 00:38:33,160
Organizations typically design blueprints along risk tiers to provide a practical way to segment

862
00:38:33,160 --> 00:38:34,640
governance complexity.

863
00:38:34,640 --> 00:38:39,160
Low-risk blueprints govern agents that read internal knowledge bases like documentation,

864
00:38:39,160 --> 00:38:41,160
FAQs and process guides.

865
00:38:41,160 --> 00:38:45,200
These agents don't touch sensitive data and can't modify anything so they operate with minimal

866
00:38:45,200 --> 00:38:49,080
human oversight because the downside of them acting autonomously is just wrong information

867
00:38:49,080 --> 00:38:52,600
rather than system damage you can approve these quickly and let them run.

868
00:38:52,600 --> 00:38:56,600
Medium-risk blueprints cover agents that can read and modify internal systems such as an

869
00:38:56,600 --> 00:38:59,240
HR workflow agent or procurement agent.

870
00:38:59,240 --> 00:39:02,440
These need human approval for certain operations especially rights.

871
00:39:02,440 --> 00:39:07,000
And while they can read data autonomously, modifications require explicit authorization.

872
00:39:07,000 --> 00:39:10,720
You review these quarterly or whenever their permissions change to ensure they stay within

873
00:39:10,720 --> 00:39:12,240
their intended scope.

874
00:39:12,240 --> 00:39:16,880
High-risk blueprints protect agents that touch sensitive data or execute critical operations

875
00:39:16,880 --> 00:39:19,880
like an agent accessing customer financial information.

876
00:39:19,880 --> 00:39:23,920
Every single operation requires human in the loop approval meaning the agent cannot act

877
00:39:23,920 --> 00:39:25,160
autonomously at all.

878
00:39:25,160 --> 00:39:29,240
It exists to assist, gather information and recommend but the human always makes the final

879
00:39:29,240 --> 00:39:30,240
decision.

880
00:39:30,240 --> 00:39:33,680
Here is a concrete example of an IT support agent in the medium-risk tier designed to

881
00:39:33,680 --> 00:39:35,480
triage support tickets.

882
00:39:35,480 --> 00:39:39,520
Its permissions include read access to service now tickets in the knowledge base but it is restricted

883
00:39:39,520 --> 00:39:42,640
from closing tickets or accessing customer data.

884
00:39:42,640 --> 00:39:46,880
If the agent encounters a critical issue like a production outage, its approval workflow

885
00:39:46,880 --> 00:39:49,400
forces it to escalate to a senior technician.

886
00:39:49,400 --> 00:39:53,640
The life cycle is reviewed quarterly and any changes to its permissions require explicit

887
00:39:53,640 --> 00:39:55,240
security team approval.

888
00:39:55,240 --> 00:39:58,720
The operational reality is that blueprints aren't designed in isolation so you must work

889
00:39:58,720 --> 00:40:00,600
with business teams to understand their needs.

890
00:40:00,600 --> 00:40:04,200
You work with security to define the constraints and compliance to ensure the policy is

891
00:40:04,200 --> 00:40:06,280
auditable then you iterate.

892
00:40:06,280 --> 00:40:09,680
As agents build from this blueprint actually operate you learn whether the design was

893
00:40:09,680 --> 00:40:11,840
right and adjust for edge cases.

894
00:40:11,840 --> 00:40:15,760
The governance benefit is multiplication because you design the policy once and hundreds

895
00:40:15,760 --> 00:40:17,000
of agents inherited.

896
00:40:17,000 --> 00:40:20,880
When you need to tighten controls or respond to a security incident you simply update the

897
00:40:20,880 --> 00:40:21,880
blueprint.

898
00:40:21,880 --> 00:40:26,720
Every agent using it inherits the change immediately which eliminates per agent reconfiguration

899
00:40:26,720 --> 00:40:28,160
and prevents policy drift.

900
00:40:28,160 --> 00:40:32,160
That is how you scale governance from five agents to five hundred without drowning in

901
00:40:32,160 --> 00:40:33,320
administration.

902
00:40:33,320 --> 00:40:37,040
The approval and life cycle workflow, how agents get born and die.

903
00:40:37,040 --> 00:40:40,560
Agents don't just appear out of nowhere, someone has to build them, someone has to decide

904
00:40:40,560 --> 00:40:44,080
if they're allowed to run, someone has to watch them and eventually someone has to turn

905
00:40:44,080 --> 00:40:45,080
them off.

906
00:40:45,080 --> 00:40:48,200
That journey from the first idea to retirement isn't an accident.

907
00:40:48,200 --> 00:40:51,600
It's the operational model that makes your control plane actually work because without a

908
00:40:51,600 --> 00:40:54,200
structured life cycle you get chaos.

909
00:40:54,200 --> 00:40:58,280
Teams start building agents in the shadows, nothing gets tracked, stale agents pile up

910
00:40:58,280 --> 00:41:00,680
because nobody remembers they exist.

911
00:41:00,680 --> 00:41:04,340
Companies never get reviewed, that's the current state in most organizations but with a life

912
00:41:04,340 --> 00:41:05,340
cycle.

913
00:41:05,340 --> 00:41:08,640
Approval becomes a gate, it stops dangerous agents from running while making the safe ones

914
00:41:08,640 --> 00:41:09,640
move faster.

915
00:41:09,640 --> 00:41:13,880
The process starts with a request, a team wants to build an agent to automate expense reports

916
00:41:13,880 --> 00:41:18,320
or triage support tickets or just summarize their daily emails, whatever the use case is,

917
00:41:18,320 --> 00:41:19,320
they have to describe it.

918
00:41:19,320 --> 00:41:20,320
What does it do?

919
00:41:20,320 --> 00:41:21,320
What data does it touch?

920
00:41:21,320 --> 00:41:22,320
Who is it for?

921
00:41:22,320 --> 00:41:24,000
That request goes to an agent governance board.

922
00:41:24,000 --> 00:41:27,560
These aren't just random executives, they are people from security and architecture who

923
00:41:27,560 --> 00:41:29,360
understand your risk tolerance.

924
00:41:29,360 --> 00:41:30,600
When comes the design review?

925
00:41:30,600 --> 00:41:34,320
The board looks at the request and asks the hard questions, is this agent's purpose narrow

926
00:41:34,320 --> 00:41:35,320
enough?

927
00:41:35,320 --> 00:41:36,960
We approve agents that do three things.

928
00:41:36,960 --> 00:41:40,200
Agents that try to do everything usually fail or they create massive risk.

929
00:41:40,200 --> 00:41:42,000
They look at the data domains.

930
00:41:42,000 --> 00:41:44,440
Customer data is too vague for a real policy.

931
00:41:44,440 --> 00:41:47,600
Read only access to billing addresses for invoices is specific.

932
00:41:47,600 --> 00:41:51,280
That specificity is what determines which blueprint you use if it's a standard task and

933
00:41:51,280 --> 00:41:52,880
existing blueprint handles it.

934
00:41:52,880 --> 00:41:56,560
If it's novel, like an agent accessing data we haven't governed before, you need a new

935
00:41:56,560 --> 00:41:57,560
blueprint.

936
00:41:57,560 --> 00:42:00,120
You assigns that blueprint and defines the scope.

937
00:42:00,120 --> 00:42:01,720
What can this agent actually do?

938
00:42:01,720 --> 00:42:03,200
Where does a human need to step in?

939
00:42:03,200 --> 00:42:06,880
For an expense agent, maybe it handles anything under $500 alone.

940
00:42:06,880 --> 00:42:08,760
But a manager has to see anything higher.

941
00:42:08,760 --> 00:42:10,880
For a support agent, it can answer questions.

942
00:42:10,880 --> 00:42:13,760
But it can't promise a refund once the design is locked.

943
00:42:13,760 --> 00:42:14,760
You deploy.

944
00:42:14,760 --> 00:42:17,240
The team builds the agent using that approved blueprint.

945
00:42:17,240 --> 00:42:18,800
The moment it's ready, they register it.

946
00:42:18,800 --> 00:42:20,680
The agent registry isn't optional.

947
00:42:20,680 --> 00:42:23,520
The agent does not go live until it's in the system with an owner.

948
00:42:23,520 --> 00:42:24,520
A purpose.

949
00:42:24,520 --> 00:42:28,360
A central agent ID because the policies are defined at the blueprint level.

950
00:42:28,360 --> 00:42:30,000
Conditional access is applied automatically.

951
00:42:30,000 --> 00:42:31,000
Now the agent is running.

952
00:42:31,000 --> 00:42:32,160
Logs flow to your CM.

953
00:42:32,160 --> 00:42:33,440
The governance team watches.

954
00:42:33,440 --> 00:42:34,440
Is it behaving?

955
00:42:34,440 --> 00:42:35,440
Is it touching files?

956
00:42:35,440 --> 00:42:36,440
It shouldn't.

957
00:42:36,440 --> 00:42:40,000
If the agent starts making more requests than usual or breaks its historical pattern, alerts

958
00:42:40,000 --> 00:42:41,000
fire.

959
00:42:41,000 --> 00:42:44,560
If the risk score crosses a threshold, conditional access can block it instantly.

960
00:42:44,560 --> 00:42:47,640
Then you have the regular reviews every quarter or every year.

961
00:42:47,640 --> 00:42:49,440
You ask if this agent is still needed.

962
00:42:49,440 --> 00:42:53,400
If usage has dropped to zero over six months, that's a signal to retire it.

963
00:42:53,400 --> 00:42:54,400
Retirement is the final phase.

964
00:42:54,400 --> 00:42:56,000
The agent is disabled.

965
00:42:56,000 --> 00:42:57,000
Permissions are revoked.

966
00:42:57,000 --> 00:42:59,280
The data it accessed is reviewed for compliance.

967
00:42:59,280 --> 00:43:01,080
The agent is removed from the directory.

968
00:43:01,080 --> 00:43:02,600
And the whole thing is audited.

969
00:43:02,600 --> 00:43:03,760
Who approved the retirement?

970
00:43:03,760 --> 00:43:04,760
When?

971
00:43:04,760 --> 00:43:05,760
Why?

972
00:43:05,760 --> 00:43:07,760
That audit trail proves the agent didn't just disappear into a black hole.

973
00:43:07,760 --> 00:43:08,840
Here's the reality.

974
00:43:08,840 --> 00:43:11,080
This process isn't a bottleneck if you design it right.

975
00:43:11,080 --> 00:43:13,360
Approval should take days, not weeks.

976
00:43:13,360 --> 00:43:15,120
Monitoring should be automated.

977
00:43:15,120 --> 00:43:17,400
Retirement should happen by itself for unused agents.

978
00:43:17,400 --> 00:43:20,360
When the operations are right, the life cycle accelerates innovation.

979
00:43:20,360 --> 00:43:21,920
It doesn't block it.

980
00:43:21,920 --> 00:43:26,120
No AI discovery and risk triage, finding the agents you don't know about.

981
00:43:26,120 --> 00:43:30,040
Right now, your organization has agents running that you don't know about.

982
00:43:30,040 --> 00:43:31,280
It's not because you're incompetent.

983
00:43:31,280 --> 00:43:33,760
It's because building agents has become too easy.

984
00:43:33,760 --> 00:43:35,000
And governance hasn't caught up.

985
00:43:35,000 --> 00:43:36,840
A team in finance discovers bedrock.

986
00:43:36,840 --> 00:43:38,680
They build an agent to analyze expenses.

987
00:43:38,680 --> 00:43:41,960
It works perfectly, so they just deploy it without telling IT.

988
00:43:41,960 --> 00:43:42,960
Marketing hears about it.

989
00:43:42,960 --> 00:43:46,200
They spin up an agent in co-pilot studio to draft social posts.

990
00:43:46,200 --> 00:43:48,400
Again, no formal process.

991
00:43:48,400 --> 00:43:52,600
The product manager built something in Azure AI Foundry to help prioritize features.

992
00:43:52,600 --> 00:43:55,480
Three agents, three platforms, zero registration.

993
00:43:55,480 --> 00:43:58,160
This isn't Males, it's just how organizations work.

994
00:43:58,160 --> 00:44:00,040
Teams move fast to solve problems.

995
00:44:00,040 --> 00:44:01,440
And governance is usually slow.

996
00:44:01,440 --> 00:44:03,400
That gap gets filled with shadow AI.

997
00:44:03,400 --> 00:44:05,840
The discovery process starts with an inventory.

998
00:44:05,840 --> 00:44:07,360
You scan the obvious spots first.

999
00:44:07,360 --> 00:44:10,960
Co-pilot studio, Azure, AWS, Google, Salesforce.

1000
00:44:10,960 --> 00:44:12,560
You look at API usage patterns.

1001
00:44:12,560 --> 00:44:16,520
If an app is making thousands of graph API queries to read email and move data, that's

1002
00:44:16,520 --> 00:44:17,520
probably an agent.

1003
00:44:17,520 --> 00:44:18,520
You just talk to people.

1004
00:44:18,520 --> 00:44:22,520
You'd be surprised how many teams have automation running in Zapier or N8N that you never

1005
00:44:22,520 --> 00:44:23,520
knew existed.

1006
00:44:23,520 --> 00:44:25,440
You aren't trying to catch people doing something wrong.

1007
00:44:25,440 --> 00:44:27,840
You're trying to understand the actual state of your environment.

1008
00:44:27,840 --> 00:44:28,840
What exists?

1009
00:44:28,840 --> 00:44:29,840
And who built it?

1010
00:44:29,840 --> 00:44:31,680
That honesty is the starting point for governance.

1011
00:44:31,680 --> 00:44:33,320
Once you have the list, you triage.

1012
00:44:33,320 --> 00:44:35,720
For every agent you find, you ask five things.

1013
00:44:35,720 --> 00:44:36,720
What is the purpose?

1014
00:44:36,720 --> 00:44:37,720
Who owns it?

1015
00:44:37,720 --> 00:44:38,720
What data does it see?

1016
00:44:38,720 --> 00:44:39,720
Is it actually being used?

1017
00:44:39,720 --> 00:44:41,040
Does it have any controls?

1018
00:44:41,040 --> 00:44:43,600
Those answers put the agent into a three-color system.

1019
00:44:43,600 --> 00:44:44,600
Green is low risk.

1020
00:44:44,600 --> 00:44:46,120
Read only access to internal knowledge.

1021
00:44:46,120 --> 00:44:47,480
No way to change or delete data.

1022
00:44:47,480 --> 00:44:48,480
You fast-track these.

1023
00:44:48,480 --> 00:44:49,480
They get registered.

1024
00:44:49,480 --> 00:44:52,200
Assign the blueprint and brought into the fold quickly.

1025
00:44:52,200 --> 00:44:55,520
The owner gets a note saying, "Your agent is now governed.

1026
00:44:55,520 --> 00:44:57,120
Here are the policies that apply.

1027
00:44:57,120 --> 00:44:58,120
Yellow is medium risk.

1028
00:44:58,120 --> 00:45:00,760
It has right access or a touch of sensitive data.

1029
00:45:00,760 --> 00:45:02,040
These agents need more structure.

1030
00:45:02,040 --> 00:45:04,360
You don't disable them, but you add requirements.

1031
00:45:04,360 --> 00:45:06,400
Maybe it needs human approval for certain steps.

1032
00:45:06,400 --> 00:45:08,200
Maybe it needs more frequent reviews.

1033
00:45:08,200 --> 00:45:09,440
Read is an immediate concern.

1034
00:45:09,440 --> 00:45:11,200
No owner, no controls.

1035
00:45:11,200 --> 00:45:13,280
Accessing sensitive data with no restrictions.

1036
00:45:13,280 --> 00:45:15,880
Read agents get disabled first and investigate it second.

1037
00:45:15,880 --> 00:45:17,680
You shut them down to prevent damage.

1038
00:45:17,680 --> 00:45:21,520
Then you figure out if they served a real purpose that needs to be rebuilt the right way.

1039
00:45:21,520 --> 00:45:23,160
But here's the critical insight.

1040
00:45:23,160 --> 00:45:24,800
Discovery isn't a one-time event.

1041
00:45:24,800 --> 00:45:26,440
New agents appear every day.

1042
00:45:26,440 --> 00:45:28,880
Teams won't stop building just because you have a framework now.

1043
00:45:28,880 --> 00:45:30,960
The process has to run continuously.

1044
00:45:30,960 --> 00:45:33,360
Automated scans find the technical footprints.

1045
00:45:33,360 --> 00:45:35,200
And manual interviews find what the scans missed.

1046
00:45:35,200 --> 00:45:36,920
The goal is zero shadow AI.

1047
00:45:36,920 --> 00:45:38,720
Not because you want to stop innovation.

1048
00:45:38,720 --> 00:45:42,480
But because an ungoverned agent undermines everything else you've built.

1049
00:45:42,480 --> 00:45:45,600
Every agent outside the system is a hole in your defense.

1050
00:45:45,600 --> 00:45:49,000
One-time enforcement and incident response when agents go wrong.

1051
00:45:49,000 --> 00:45:50,720
Good policy prevents most problems.

1052
00:45:50,720 --> 00:45:54,600
The right blueprint stops agents from touching data they shouldn't see.

1053
00:45:54,600 --> 00:45:56,720
Conditional access blocks actions that look wrong.

1054
00:45:56,720 --> 00:45:59,200
DLP stops data from leaking to the wrong places.

1055
00:45:59,200 --> 00:46:00,520
But policy is defensive.

1056
00:46:00,520 --> 00:46:01,640
It sets the boundaries.

1057
00:46:01,640 --> 00:46:04,880
It doesn't stop a determined attacker or a new vulnerability.

1058
00:46:04,880 --> 00:46:06,960
An agent's code gets manipulated.

1059
00:46:06,960 --> 00:46:10,680
It's prompt gets injected or an attacker takes over the hosting environment.

1060
00:46:10,680 --> 00:46:12,480
Something breaks the model's assumptions.

1061
00:46:12,480 --> 00:46:14,280
When that happens, what stops the damage?

1062
00:46:14,280 --> 00:46:16,840
Many mechanisms work together in a sequence.

1063
00:46:16,840 --> 00:46:18,840
Enforcement, detection and response.

1064
00:46:18,840 --> 00:46:20,720
They aren't just set up a deployment and forgotten.

1065
00:46:20,720 --> 00:46:24,160
They run constantly checking risk and making decisions in real time.

1066
00:46:24,160 --> 00:46:27,280
The enforcement layer stops bad actions at the token level.

1067
00:46:27,280 --> 00:46:31,360
If an agent tries to open a confidential file without the right token, the request fails

1068
00:46:31,360 --> 00:46:32,360
immediately.

1069
00:46:32,360 --> 00:46:35,960
Conditional access sees the request is outside the agent's normal routine and blocks it.

1070
00:46:35,960 --> 00:46:40,200
At the same time, DLP sees the agent trying to send customer records to a personal email

1071
00:46:40,200 --> 00:46:41,840
and prevents the violation.

1072
00:46:41,840 --> 00:46:46,600
It limits the agent's 50,000 api calls per minute and throttles the connection.

1073
00:46:46,600 --> 00:46:50,200
These controls work on their own, so if one fails, the others are there to catch it.

1074
00:46:50,200 --> 00:46:53,200
The detection layer finds the problems that enforcement missed.

1075
00:46:53,200 --> 00:46:56,600
Logs from every system the agent touches flow into a central CM.

1076
00:46:56,600 --> 00:47:00,440
An anomaly engine looks at these logs in real time to understand what normal looks like

1077
00:47:00,440 --> 00:47:01,800
for this specific agent.

1078
00:47:01,800 --> 00:47:05,800
It knows how often it runs, what it does, and how much data it usually handles.

1079
00:47:05,800 --> 00:47:08,000
When the behavior changes, a signal fires.

1080
00:47:08,000 --> 00:47:12,600
If an agent that usually reads 10 emails an hour suddenly reads 10,000, the system notices

1081
00:47:12,600 --> 00:47:16,360
the anomaly, risks scoring automatically bumps up the threat level.

1082
00:47:16,360 --> 00:47:20,640
Analytics flag patterns that suggest a compromise, like an agent creating dozens of mailbox rules

1083
00:47:20,640 --> 00:47:22,000
when it has never done that before.

1084
00:47:22,000 --> 00:47:23,000
The system sees it.

1085
00:47:23,000 --> 00:47:27,000
The response layer moves when detection flags a problem, and alert hits your security operation

1086
00:47:27,000 --> 00:47:30,840
center, and the SOC team gets notified that an agent is acting out.

1087
00:47:30,840 --> 00:47:33,880
They don't have to guess what is happening because they can see the specific actions

1088
00:47:33,880 --> 00:47:35,360
and the policy evaluations.

1089
00:47:35,360 --> 00:47:38,800
They see exactly what the agent tried to do and what stopped it.

1090
00:47:38,800 --> 00:47:41,320
Investigations moves fast because the context is right there.

1091
00:47:41,320 --> 00:47:44,600
If the agent is actually compromised, containment happens right away.

1092
00:47:44,600 --> 00:47:49,040
Permissions are revoked, conditional access blocks new requests, and the agent stops before

1093
00:47:49,040 --> 00:47:50,600
any more damage occurs.

1094
00:47:50,600 --> 00:47:52,080
Remediation comes next.

1095
00:47:52,080 --> 00:47:56,680
You have to figure out if the agent itself was the problem, or if the environment was breached,

1096
00:47:56,680 --> 00:48:00,520
you check if it was a code flaw that needs a patch or if the prompt was manipulated.

1097
00:48:00,520 --> 00:48:02,240
Different causes need different fixes.

1098
00:48:02,240 --> 00:48:06,560
You rotate the credentials, redeploy the code, and look at what the agent accessed while

1099
00:48:06,560 --> 00:48:07,560
it was active.

1100
00:48:07,560 --> 00:48:11,360
You restore data if you have to, and document everything so the team learns from the incident.

1101
00:48:11,360 --> 00:48:13,040
Learning is the final piece of the model.

1102
00:48:13,040 --> 00:48:16,240
The team reviews the incident to see if the policy should have caught it earlier.

1103
00:48:16,240 --> 00:48:20,720
They ask if the blueprint was too loose, or if the detection rules missed something obvious.

1104
00:48:20,720 --> 00:48:21,880
These aren't about blame.

1105
00:48:21,880 --> 00:48:23,160
They are about design.

1106
00:48:23,160 --> 00:48:26,400
You adjust the policy, update the blueprints, and sharpen the detection.

1107
00:48:26,400 --> 00:48:30,080
The next time someone tries this, the response is faster and the damage is smaller.

1108
00:48:30,080 --> 00:48:31,080
Look at a real scenario.

1109
00:48:31,080 --> 00:48:34,480
Document agent starts sending contract text to an outside email address.

1110
00:48:34,480 --> 00:48:36,400
The enforcement layers activate immediately.

1111
00:48:36,400 --> 00:48:40,640
DLP sees customer contracts going to an unauthorized address and blocks the transfer.

1112
00:48:40,640 --> 00:48:42,280
The agent can't finish the job.

1113
00:48:42,280 --> 00:48:44,680
Detection notices the anomaly at the same time.

1114
00:48:44,680 --> 00:48:48,720
This agent has never talked to this email address before, which is completely outside its

1115
00:48:48,720 --> 00:48:49,720
normal pattern.

1116
00:48:49,720 --> 00:48:52,440
The risk scores spikes to critical and the agent gets flagged.

1117
00:48:52,440 --> 00:48:54,920
The SOC team gets the alert and looks at the logs.

1118
00:48:54,920 --> 00:48:58,280
They see the blocked attempt and check the agent's history, finding nothing wrong until

1119
00:48:58,280 --> 00:48:59,280
that moment.

1120
00:48:59,280 --> 00:49:02,640
They check the environment and find a prompt injection attack where someone used specific

1121
00:49:02,640 --> 00:49:04,160
input to trick the agent.

1122
00:49:04,160 --> 00:49:07,840
They rotate the credentials, fix the prompt safeguards, and check the data.

1123
00:49:07,840 --> 00:49:10,640
The contract's never left the building because enforcement stopped it.

1124
00:49:10,640 --> 00:49:13,560
The whole process from detection to containment takes minutes.

1125
00:49:13,560 --> 00:49:17,640
It is prevention focused instead of just reacting to a disaster.

1126
00:49:17,640 --> 00:49:21,760
From governance silos to unified AI policy, breaking down walls.

1127
00:49:21,760 --> 00:49:26,240
For 15 years, companies have organized themselves around a simple idea.

1128
00:49:26,240 --> 00:49:28,880
Identity governance and security governance are different problems.

1129
00:49:28,880 --> 00:49:32,000
They are owned by different teams with different budgets and different goals.

1130
00:49:32,000 --> 00:49:35,360
The identity team handles users, groups, and access rights.

1131
00:49:35,360 --> 00:49:38,200
They own the directory and the onboarding process.

1132
00:49:38,200 --> 00:49:42,280
Their success is measured by how many access reviews they finish or how fast they get a new

1133
00:49:42,280 --> 00:49:43,520
hire into the system.

1134
00:49:43,520 --> 00:49:46,440
The security team focuses on threats and incident response.

1135
00:49:46,440 --> 00:49:48,640
They run the CM and hunt for breaches.

1136
00:49:48,640 --> 00:49:52,040
Their success is measured by how fast they detect and contain a threat.

1137
00:49:52,040 --> 00:49:54,200
The compliance team handles the audits and the paperwork.

1138
00:49:54,200 --> 00:49:55,800
They prove the controls exist.

1139
00:49:55,800 --> 00:49:59,800
The data governance team classifies info and manages how long it stays in the system.

1140
00:49:59,800 --> 00:50:01,440
They own the data dictionary.

1141
00:50:01,440 --> 00:50:04,080
These teams rarely talk to each other unless something went wrong.

1142
00:50:04,080 --> 00:50:07,560
An audit failure or a breach would force them into a room together, but usually they

1143
00:50:07,560 --> 00:50:09,080
worked on parallel tracks.

1144
00:50:09,080 --> 00:50:11,800
The identity team didn't think about data sensitivity.

1145
00:50:11,800 --> 00:50:15,680
The security team didn't know which classifications applied to which systems.

1146
00:50:15,680 --> 00:50:19,800
The compliance team wrote down rules without knowing if they were actually being enforced.

1147
00:50:19,800 --> 00:50:22,760
This split worked for a long time because the world was smaller.

1148
00:50:22,760 --> 00:50:25,000
People used apps and apps used databases.

1149
00:50:25,000 --> 00:50:27,720
The perimeter was stable and policy moved slowly.

1150
00:50:27,720 --> 00:50:31,080
You could afford to work in silos because the mistakes didn't hurt you as often.

1151
00:50:31,080 --> 00:50:33,600
AI agents break this model completely.

1152
00:50:33,600 --> 00:50:35,680
An agent doesn't fit into a single bucket.

1153
00:50:35,680 --> 00:50:37,600
It is an identity that needs to be authorized.

1154
00:50:37,600 --> 00:50:39,880
It is a security risk that can be exploited.

1155
00:50:39,880 --> 00:50:42,840
It handles sensitive data that compliance cares about.

1156
00:50:42,840 --> 00:50:45,360
It operates under rules that regulate classified info.

1157
00:50:45,360 --> 00:50:48,640
You can't govern an agent by having four different teams do their own thing and hoping

1158
00:50:48,640 --> 00:50:49,640
it works out.

1159
00:50:49,640 --> 00:50:51,400
The unified approach changes that.

1160
00:50:51,400 --> 00:50:53,800
Identity governance becomes part of AI governance.

1161
00:50:53,800 --> 00:50:57,360
The question of what an agent can do is answered by one policy framework.

1162
00:50:57,360 --> 00:51:01,240
Security rules like conditional access now apply to agents just as much as they apply to

1163
00:51:01,240 --> 00:51:02,240
people.

1164
00:51:02,240 --> 00:51:05,280
Compliance and audit trails are built into the identity layer from the start.

1165
00:51:05,280 --> 00:51:08,080
Data classification is tied directly to agent permissions.

1166
00:51:08,080 --> 00:51:11,400
If an agent isn't cleared for a certain type of data, it can't touch it.

1167
00:51:11,400 --> 00:51:14,920
If data is set to be deleted, the agent's access ends automatically.

1168
00:51:14,920 --> 00:51:16,520
The organizational shift is huge.

1169
00:51:16,520 --> 00:51:19,400
You need a cross-functional team that most companies just don't have yet.

1170
00:51:19,400 --> 00:51:22,680
You can't have identity security and data people working one after the other.

1171
00:51:22,680 --> 00:51:25,600
You need them in the same room designing policy together.

1172
00:51:25,600 --> 00:51:28,800
When someone requests a new agent, the whole team reviews it at once.

1173
00:51:28,800 --> 00:51:30,560
The identity architect checks the blueprint.

1174
00:51:30,560 --> 00:51:32,680
The security engineer looks for exploits.

1175
00:51:32,680 --> 00:51:34,560
The compliance officer checks the audit trail.

1176
00:51:34,560 --> 00:51:36,600
The data Stuart looks at the classifications.

1177
00:51:36,600 --> 00:51:37,960
This is a cultural change.

1178
00:51:37,960 --> 00:51:40,040
The old way was, security says no.

1179
00:51:40,040 --> 00:51:43,040
The new way is, security builds the guardrails.

1180
00:51:43,040 --> 00:51:44,840
Compliance moves from a checkbox to code.

1181
00:51:44,840 --> 00:51:47,760
Data governance moves from spreadsheets to active enforcement.

1182
00:51:47,760 --> 00:51:49,840
This needs the C suite to step in.

1183
00:51:49,840 --> 00:51:53,960
One of the top has to say that AI governance is the priority and that the silos are over.

1184
00:51:53,960 --> 00:51:55,480
Every team owns a piece of the result.

1185
00:51:55,480 --> 00:51:58,240
It takes investment in tools, training and a new structure.

1186
00:51:58,240 --> 00:51:59,240
It takes time.

1187
00:51:59,240 --> 00:52:01,320
But when you get it right, the payoff is worth it.

1188
00:52:01,320 --> 00:52:03,280
The speed versus security tradeoff.

1189
00:52:03,280 --> 00:52:05,120
How to scale without losing control.

1190
00:52:05,120 --> 00:52:08,000
The moment you bring up governance, you'll hear the same objection.

1191
00:52:08,000 --> 00:52:09,600
People will call it IT bureaucracy.

1192
00:52:09,600 --> 00:52:11,080
They'll say it slows them down.

1193
00:52:11,080 --> 00:52:12,720
They'll tell you they need to move fast.

1194
00:52:12,720 --> 00:52:15,280
The people saying this aren't wrong about the tension.

1195
00:52:15,280 --> 00:52:17,640
Speed and control usually pull in different directions.

1196
00:52:17,640 --> 00:52:19,120
But they're wrong about the result.

1197
00:52:19,120 --> 00:52:20,480
Some governance doesn't slow you down.

1198
00:52:20,480 --> 00:52:22,000
It actually enables speed.

1199
00:52:22,000 --> 00:52:25,160
And the moment your team understand that, the resistance disappears.

1200
00:52:25,160 --> 00:52:27,440
So what's actually happening is a shift in the math.

1201
00:52:27,440 --> 00:52:29,960
Blueprints remove the friction at the point of creation.

1202
00:52:29,960 --> 00:52:34,320
In the old model, a team wants to build an agent and they submit a formal request.

1203
00:52:34,320 --> 00:52:35,320
Security reviews it.

1204
00:52:35,320 --> 00:52:36,320
They ask questions.

1205
00:52:36,320 --> 00:52:37,320
The team answers.

1206
00:52:37,320 --> 00:52:38,320
Security asks more questions.

1207
00:52:38,320 --> 00:52:40,480
Weeks pass while everyone is stuck in a back and forth.

1208
00:52:40,480 --> 00:52:42,160
And the team stays blocked.

1209
00:52:42,160 --> 00:52:43,720
Blueprints collapse that entire timeline.

1210
00:52:43,720 --> 00:52:47,600
Now, the team just looks at your approved Blueprint catalog and finds one that matches their

1211
00:52:47,600 --> 00:52:48,600
use case.

1212
00:52:48,600 --> 00:52:51,600
They build the agent using that pre-approved pattern.

1213
00:52:51,600 --> 00:52:54,720
And it gets the green light in days because the policy decisions were already made.

1214
00:52:54,720 --> 00:52:57,720
You aren't designing permissions from scratch for every single agent.

1215
00:52:57,720 --> 00:52:59,840
You're just using patterns that already exist.

1216
00:52:59,840 --> 00:53:02,920
Automation removes the manual steps that kill momentum.

1217
00:53:02,920 --> 00:53:06,040
Traditional approval workflows are slow because they rely on humans.

1218
00:53:06,040 --> 00:53:07,120
Someone gets an email.

1219
00:53:07,120 --> 00:53:08,120
They read it.

1220
00:53:08,120 --> 00:53:11,080
They decide they reply every single one of those steps takes time.

1221
00:53:11,080 --> 00:53:14,600
But when you enforce policies at the identity layer, you don't need human intervention

1222
00:53:14,600 --> 00:53:16,440
unless something is actually wrong.

1223
00:53:16,440 --> 00:53:20,960
If an agent tries to do something that violates a policy, the system blocks it instantly.

1224
00:53:20,960 --> 00:53:21,960
There is no email.

1225
00:53:21,960 --> 00:53:22,960
There is no waiting.

1226
00:53:22,960 --> 00:53:26,960
It's just automatic.

1227
00:53:26,960 --> 00:53:31,400
Clear guidelines stop the constant back and forth that destroys velocity.

1228
00:53:31,400 --> 00:53:34,520
When teams don't know what's allowed, they feel like they have to ask permission for

1229
00:53:34,520 --> 00:53:35,520
everything.

1230
00:53:35,520 --> 00:53:39,280
They ask if this is okay or if they can try that and every question becomes a conversation

1231
00:53:39,280 --> 00:53:40,760
that causes a delay.

1232
00:53:40,760 --> 00:53:42,680
Blueprints make the rules explicit.

1233
00:53:42,680 --> 00:53:46,400
You can tell a team exactly what an agent with a specific blueprint is allowed to do.

1234
00:53:46,400 --> 00:53:47,720
There is no ambiguity.

1235
00:53:47,720 --> 00:53:49,520
Teams read the rules and move forward.

1236
00:53:49,520 --> 00:53:52,920
And they ask fewer questions because the answers are already documented.

1237
00:53:52,920 --> 00:53:54,600
But here's the problem people miss.

1238
00:53:54,600 --> 00:53:56,400
Prevention is always faster than response.

1239
00:53:56,400 --> 00:54:00,560
If a team discovers an agent is stealing data in the old model, they spend weeks investigating

1240
00:54:00,560 --> 00:54:01,560
the mess.

1241
00:54:01,560 --> 00:54:05,320
They have to figure out how it happened, how much data left and what systems were touched.

1242
00:54:05,320 --> 00:54:06,520
They have no audit trail.

1243
00:54:06,520 --> 00:54:10,520
So they're stuck reconstructing events from broken logs while the business is disrupted.

1244
00:54:10,520 --> 00:54:13,160
In the govern model, that data theft never happens.

1245
00:54:13,160 --> 00:54:14,960
The policy blocks it in real time.

1246
00:54:14,960 --> 00:54:17,480
The investigation is simple because the system caught it.

1247
00:54:17,480 --> 00:54:19,760
The evidence is right there and the business keeps running.

1248
00:54:19,760 --> 00:54:21,280
The real bottleneck isn't governance.

1249
00:54:21,280 --> 00:54:22,280
It's clarity.

1250
00:54:22,280 --> 00:54:24,600
Teams move slowly when they don't know what's allowed.

1251
00:54:24,600 --> 00:54:25,600
They get cautious.

1252
00:54:25,600 --> 00:54:26,600
They ask for permission.

1253
00:54:26,600 --> 00:54:27,600
They wait.

1254
00:54:27,600 --> 00:54:30,120
But teams move fast when they know the rules and understand the guardrails.

1255
00:54:30,120 --> 00:54:33,320
They know exactly what they can do on their own and where they need a sign off.

1256
00:54:33,320 --> 00:54:35,840
They build within those lines and they don't have to wait.

1257
00:54:35,840 --> 00:54:37,400
This is the model you're actually building.

1258
00:54:37,400 --> 00:54:40,480
The fast path is for agents that fit existing blueprints.

1259
00:54:40,480 --> 00:54:43,600
These don't need a security review because the security decisions are already baked

1260
00:54:43,600 --> 00:54:44,840
into the blueprint itself.

1261
00:54:44,840 --> 00:54:48,200
They don't need custom approvals because the standard workflows already apply.

1262
00:54:48,200 --> 00:54:49,800
You can get these approved in days.

1263
00:54:49,800 --> 00:54:52,640
In a healthy system, this should be the majority.

1264
00:54:52,640 --> 00:54:56,920
Maybe 70 or 80% of your agents will fit these existing patterns.

1265
00:54:56,920 --> 00:55:00,960
The medium path is for agents that need a few tweaks to an existing blueprint.

1266
00:55:00,960 --> 00:55:03,360
Maybe you have a blueprint for internal data access.

1267
00:55:03,360 --> 00:55:06,240
But a new use case needs to touch a different data domain.

1268
00:55:06,240 --> 00:55:07,760
You design a narrow variation.

1269
00:55:07,760 --> 00:55:11,240
The security review is focused and quick, usually taking one to two weeks.

1270
00:55:11,240 --> 00:55:13,520
Most teams find that timeline perfectly reasonable.

1271
00:55:13,520 --> 00:55:15,880
The slow path is only for the truly weird stuff.

1272
00:55:15,880 --> 00:55:18,760
These are the novel agents with unique requirements or high risks.

1273
00:55:18,760 --> 00:55:20,480
They need custom designs and long reviews.

1274
00:55:20,480 --> 00:55:22,320
You might spend weeks in discussions.

1275
00:55:22,320 --> 00:55:23,320
But these should be rare.

1276
00:55:23,320 --> 00:55:26,000
We're talking 5 or 10% of your agents at most.

1277
00:55:26,000 --> 00:55:28,600
And if you want to know if this is working, look at the metrics.

1278
00:55:28,600 --> 00:55:32,320
How long does it take to get from a request to a deployment on the fast path?

1279
00:55:32,320 --> 00:55:34,080
If it's under a week, you're enabling speed.

1280
00:55:34,080 --> 00:55:36,880
What percentage of your agents are actually using that fast path?

1281
00:55:36,880 --> 00:55:40,200
If it's over 70%, your blueprint catalog is doing its job.

1282
00:55:40,200 --> 00:55:42,160
You should also track your incident rate.

1283
00:55:42,160 --> 00:55:44,800
Because fewer incidents mean the governance is actually holding.

1284
00:55:44,800 --> 00:55:48,480
If agent adoption is accelerating, then you know governance isn't a bottleneck.

1285
00:55:48,480 --> 00:55:49,840
The goal is simple.

1286
00:55:49,840 --> 00:55:52,160
Governance should be invisible to teams that follow the rules.

1287
00:55:52,160 --> 00:55:54,600
It only shows up when someone tries to break a policy.

1288
00:55:54,600 --> 00:55:56,880
And when it does appear, the blocker should be clear.

1289
00:55:56,880 --> 00:55:58,960
Not some mysterious piece of bureaucracy.

1290
00:55:58,960 --> 00:56:02,480
You tell them they can't access that data because the blueprint doesn't allow it.

1291
00:56:02,480 --> 00:56:04,800
And then you show them how to request a variation.

1292
00:56:04,800 --> 00:56:05,960
Teams understand that.

1293
00:56:05,960 --> 00:56:09,720
They either accept the limit or they start the right process to change it.

1294
00:56:09,720 --> 00:56:11,120
Roads and responsibilities.

1295
00:56:11,120 --> 00:56:12,120
Who owns what?

1296
00:56:12,120 --> 00:56:17,160
Moving from siloed governance to a unified policy means you need total clarity on who does what.

1297
00:56:17,160 --> 00:56:18,760
This isn't about boxes on an org chart.

1298
00:56:18,760 --> 00:56:21,480
It's about functional responsibilities and how they overlap.

1299
00:56:21,480 --> 00:56:26,240
In the old model, IT owned identity, security handled threats, and compliance gathered ordered

1300
00:56:26,240 --> 00:56:27,240
evidence.

1301
00:56:27,240 --> 00:56:28,360
Everyone stayed in their own lane.

1302
00:56:28,360 --> 00:56:31,920
But the new model can't work like that because agents touch everything at once.

1303
00:56:31,920 --> 00:56:33,880
Let's look at the roles that actually matter.

1304
00:56:33,880 --> 00:56:38,240
The agent sponsor is usually a business owner, like a director or a department head.

1305
00:56:38,240 --> 00:56:42,220
They are accountable for whether the agent makes sense and whether it behaves itself, they

1306
00:56:42,220 --> 00:56:43,560
didn't build the code.

1307
00:56:43,560 --> 00:56:45,440
But they are responsible for why it exists.

1308
00:56:45,440 --> 00:56:48,880
They approve what the agent can touch and what actions it's allowed to take.

1309
00:56:48,880 --> 00:56:53,080
They have to review the agent regularly to see if it's still needed or if it's still following

1310
00:56:53,080 --> 00:56:54,080
the blueprint.

1311
00:56:54,080 --> 00:56:57,800
When something goes wrong and the agent causes damage, the sponsor is the one who answers

1312
00:56:57,800 --> 00:56:58,800
for it.

1313
00:56:58,800 --> 00:57:00,880
They own the decision to build it in the first place.

1314
00:57:00,880 --> 00:57:04,600
The agent owner is the technical person who actually builds and maintains the code.

1315
00:57:04,600 --> 00:57:07,800
They make sure the agent stays inside its blueprint during development.

1316
00:57:07,800 --> 00:57:11,040
If there's an incident and the agent gets compromised, they are the ones who investigate

1317
00:57:11,040 --> 00:57:12,040
and fix it.

1318
00:57:12,040 --> 00:57:16,120
They also handle the updates when organizational policies change or when the business needs shift.

1319
00:57:16,120 --> 00:57:20,160
The identity architect is the one who designs the blueprints and defines the policies.

1320
00:57:20,160 --> 00:57:24,000
They review agent requests to make sure they actually line up with the rules.

1321
00:57:24,000 --> 00:57:27,560
When a team wants to build something that doesn't fit the current blueprints, the architect

1322
00:57:27,560 --> 00:57:29,940
either finds a variation or designs a new one.

1323
00:57:29,940 --> 00:57:33,480
They also maintain the agent registry, which is the official list of what exists and

1324
00:57:33,480 --> 00:57:34,480
what it's allowed to do.

1325
00:57:34,480 --> 00:57:37,000
The security team is there to monitor agent activity.

1326
00:57:37,000 --> 00:57:40,400
They watch the logs coming in from every platform and look for anything weird.

1327
00:57:40,400 --> 00:57:43,280
When an agent starts acting suspicious, they investigate.

1328
00:57:43,280 --> 00:57:45,280
When an attack happens, they contain it.

1329
00:57:45,280 --> 00:57:49,360
They're also the ones recommending policy updates based on what they see in the real world.

1330
00:57:49,360 --> 00:57:53,760
The compliance officer makes sure the policies actually meet regulatory requirements.

1331
00:57:53,760 --> 00:57:56,800
They review the audit trails to prove the controls are working.

1332
00:57:56,800 --> 00:58:01,600
They are the ones who certified to auditors that your governance is real and not just a theory.

1333
00:58:01,600 --> 00:58:06,040
If an agent touches customer data, the compliance officer has to prove that access was authorized

1334
00:58:06,040 --> 00:58:06,960
and logged.

1335
00:58:06,960 --> 00:58:09,400
The data steward is the one who classifies the information.

1336
00:58:09,400 --> 00:58:12,280
They decide what's public, what's internal and what's confidential.

1337
00:58:12,280 --> 00:58:15,480
They define which agents can access which categories of data.

1338
00:58:15,480 --> 00:58:18,200
They also enforce the rules for how long data is kept.

1339
00:58:18,200 --> 00:58:22,360
When an agent touches sensitive info, the steward reviews it to make sure it was appropriate.

1340
00:58:22,360 --> 00:58:23,360
But here's the shift.

1341
00:58:23,360 --> 00:58:25,160
These roles have to work together.

1342
00:58:25,160 --> 00:58:28,320
When someone requests an agent, every stakeholder reviews it.

1343
00:58:28,320 --> 00:58:30,600
The sponsor makes sure it solves a business problem.

1344
00:58:30,600 --> 00:58:32,480
The architect checks the blueprint.

1345
00:58:32,480 --> 00:58:33,480
Security looks at the risk.

1346
00:58:33,480 --> 00:58:35,360
The data steward checks the data access.

1347
00:58:35,360 --> 00:58:37,440
The compliance makes sure it can be audited.

1348
00:58:37,440 --> 00:58:39,800
When an incident happens, they investigate as a team.

1349
00:58:39,800 --> 00:58:41,760
When policies change, everyone gets the memo.

1350
00:58:41,760 --> 00:58:45,080
When an agent is retired, they coordinate the shutdown together.

1351
00:58:45,080 --> 00:58:47,920
In the real world, this scales with the size of your company.

1352
00:58:47,920 --> 00:58:52,600
If you're in a 50 person startup, one person might be the architect, the security engineer,

1353
00:58:52,600 --> 00:58:54,400
and the compliance officer all at once.

1354
00:58:54,400 --> 00:58:55,640
They wear a lot of hats.

1355
00:58:55,640 --> 00:58:58,600
In a massive enterprise, these are dedicated teams with clear borders.

1356
00:58:58,600 --> 00:59:00,200
But the key is clarity.

1357
00:59:00,200 --> 00:59:02,400
Everyone needs to know what they are responsible for.

1358
00:59:02,400 --> 00:59:06,000
And when a decision affects multiple teams, the handoff has to be explicit.

1359
00:59:06,000 --> 00:59:07,680
That kind of clarity doesn't just happen.

1360
00:59:07,680 --> 00:59:11,960
It requires someone at the top, like a CISO or an enterprise architect, to set the framework

1361
00:59:11,960 --> 00:59:13,400
and keep it consistent.

1362
00:59:13,400 --> 00:59:16,400
It requires meetings where all these people actually sit down and align.

1363
00:59:16,400 --> 00:59:19,160
You have to accept that agent governance is a team sport.

1364
00:59:19,160 --> 00:59:22,640
And it's not something any single department can do alone.

1365
00:59:22,640 --> 00:59:23,640
The ROI.

1366
00:59:23,640 --> 00:59:25,400
Why this matters to the business?

1367
00:59:25,400 --> 00:59:29,080
Building a governance framework for AI agents requires real investment.

1368
00:59:29,080 --> 00:59:30,080
You need tooling.

1369
00:59:30,080 --> 00:59:31,080
You need trained people.

1370
00:59:31,080 --> 00:59:33,800
You need a company to design blueprints and establish processes.

1371
00:59:33,800 --> 00:59:35,560
And you need organizational change.

1372
00:59:35,560 --> 00:59:36,640
Which doesn't happen overnight.

1373
00:59:36,640 --> 00:59:38,320
The question isn't whether it costs something.

1374
00:59:38,320 --> 00:59:40,640
The question is whether the payoff justifies the cost.

1375
00:59:40,640 --> 00:59:41,800
The answer is yes.

1376
00:59:41,800 --> 00:59:44,160
But the payoff isn't just about preventing bad things.

1377
00:59:44,160 --> 00:59:45,880
It's about enabling good ones.

1378
00:59:45,880 --> 00:59:47,200
Start with risk reduction.

1379
00:59:47,200 --> 00:59:49,200
Because this is where the numbers are largest.

1380
00:59:49,200 --> 00:59:50,760
Every prevented breach saves money.

1381
00:59:50,760 --> 00:59:54,320
A typical enterprise data breach costs between four and five million dollars.

1382
00:59:54,320 --> 00:59:56,600
That's not just the incident response and remediation.

1383
00:59:56,600 --> 00:59:57,600
That's lost business.

1384
00:59:57,600 --> 01:00:01,080
Data-related refines, reputation damage, and the long tail of customer churn.

1385
01:00:01,080 --> 01:00:03,360
An AI agent breach could be worse.

1386
01:00:03,360 --> 01:00:07,760
An agent with broad access can cause damage at scale and speed that a human attacker couldn't match.

1387
01:00:07,760 --> 01:00:11,680
The governance framework prevents most agent-driven breaches before they happen.

1388
01:00:11,680 --> 01:00:13,320
DLP stops exfiltration.

1389
01:00:13,320 --> 01:00:15,680
Conditional access blocks anomalous behavior.

1390
01:00:15,680 --> 01:00:17,920
Audit trails enable fast detection.

1391
01:00:17,920 --> 01:00:22,920
For a large organization preventing even one serious breach pays for years of governance investment.

1392
01:00:22,920 --> 01:00:26,200
The conservative estimate one prevented breach saves one million dollars.

1393
01:00:26,200 --> 01:00:29,800
Not mature implementations prevent multiple breaches annually.

1394
01:00:29,800 --> 01:00:32,920
Incident response becomes faster when you have complete visibility.

1395
01:00:32,920 --> 01:00:37,000
In the old model, a security incident involving an agent took weeks to investigate.

1396
01:00:37,000 --> 01:00:38,320
Which agent caused the problem?

1397
01:00:38,320 --> 01:00:39,480
What did it actually access?

1398
01:00:39,480 --> 01:00:40,680
Which systems did it touch?

1399
01:00:40,680 --> 01:00:45,040
Your reconstructing events from fragmented logs in the governed model the answer is immediate.

1400
01:00:45,040 --> 01:00:49,840
The audit trail shows exactly what happened, who authorized it, and what was blocked.

1401
01:00:49,840 --> 01:00:52,440
Investigations shifts from reconstruction to confirmation.

1402
01:00:52,440 --> 01:00:56,840
The first time drops from weeks to days, every day saved his business impact reduced.

1403
01:00:56,840 --> 01:00:59,080
Compliance becomes provable instead of aspirational.

1404
01:00:59,080 --> 01:01:00,920
Regulators want audit evidence.

1405
01:01:00,920 --> 01:01:03,520
Can you show which agents accessed which data?

1406
01:01:03,520 --> 01:01:05,520
Can you prove controls were enforced?

1407
01:01:05,520 --> 01:01:10,520
In the old model, the answer is usually, we think so, but we'd have to dig through logs.

1408
01:01:10,520 --> 01:01:14,680
In the governed model, the answer is here is the structured evidence showing exactly what happened,

1409
01:01:14,680 --> 01:01:16,040
and that policy was enforced.

1410
01:01:16,040 --> 01:01:18,520
Audit costs drop because auditors don't have to dig.

1411
01:01:18,520 --> 01:01:19,920
You provide the evidence.

1412
01:01:19,920 --> 01:01:23,920
In the digital industries, the difference between we can probably prove compliance, and we

1413
01:01:23,920 --> 01:01:28,520
have definitive proof, can be the difference between a clean audit and major findings.

1414
01:01:28,520 --> 01:01:33,920
Estimate 30 to 50% reduction in audit costs and investigation burden.

1415
01:01:33,920 --> 01:01:37,680
Operational efficiency gains emerge because work that was manual becomes automated.

1416
01:01:37,680 --> 01:01:41,560
Permission review, automated through access packages and risk-based scoring.

1417
01:01:41,560 --> 01:01:46,240
Policy enforcement automated through conditional access and DLP, agent life cycle tracking,

1418
01:01:46,240 --> 01:01:51,240
audit through registry tools, security teams stop firefighting and start strategizing, identity

1419
01:01:51,240 --> 01:01:55,520
teams stop handling exception requests and start designing better blueprints.

1420
01:01:55,520 --> 01:01:59,760
Compliance teams focus on policy rather than manual evidence collection.

1421
01:01:59,760 --> 01:02:03,840
The labor cost savings alone fewer people require to do the same governance, typically runs

1422
01:02:03,840 --> 01:02:08,760
20 to 30% reduction in identity and security operations headcount.

1423
01:02:08,760 --> 01:02:11,440
Innovation enablment is where the real value multiplies.

1424
01:02:11,440 --> 01:02:14,520
When governance is clear and fast, teams build more agents.

1425
01:02:14,520 --> 01:02:18,280
They build faster because they don't have to navigate ambiguous approval processes.

1426
01:02:18,280 --> 01:02:21,000
They build more because they see the patterns that work.

1427
01:02:21,000 --> 01:02:23,200
The innovation doesn't come from removing guardrails.

1428
01:02:23,200 --> 01:02:25,360
It comes from making the guardrails transparent.

1429
01:02:25,360 --> 01:02:26,680
Teams know exactly what's allowed.

1430
01:02:26,680 --> 01:02:28,560
They know the fast path and the slow path.

1431
01:02:28,560 --> 01:02:30,360
They build accordingly.

1432
01:02:30,360 --> 01:02:34,680
Organizations that implement this model typically see 2 to 3 times more agent adoption because

1433
01:02:34,680 --> 01:02:36,680
the bottleneck disappears.

1434
01:02:36,680 --> 01:02:39,360
Data protection becomes active instead of reactive.

1435
01:02:39,360 --> 01:02:43,120
Sensitive data classifications are enforced at the agent level through permissions.

1436
01:02:43,120 --> 01:02:46,960
Information policies automatically terminate agent access when data age is, deletion happens

1437
01:02:46,960 --> 01:02:48,440
without human intervention.

1438
01:02:48,440 --> 01:02:53,000
The attacks that succeed in ungoverned data environments, lateral movement to sensitive systems,

1439
01:02:53,000 --> 01:02:57,480
data aggregation, exfiltration, don't succeed here because policy prevents them at the identity

1440
01:02:57,480 --> 01:02:58,480
layer.

1441
01:02:58,480 --> 01:03:01,600
The total ROI for a large organization is substantial.

1442
01:03:01,600 --> 01:03:05,280
Risk reduction from prevented breaches, one to two million dollars.

1443
01:03:05,280 --> 01:03:08,480
Compliance cost savings, 200 to 500,000.

1444
01:03:08,480 --> 01:03:11,680
Operational efficiency 300 to 500,000.

1445
01:03:11,680 --> 01:03:15,960
An enablement 500,000 to 1 million in new business value from agents that wouldn't have been

1446
01:03:15,960 --> 01:03:17,560
built otherwise.

1447
01:03:17,560 --> 01:03:18,960
Total tangible benefit.

1448
01:03:18,960 --> 01:03:22,280
2 to 2.5 million dollars annually.

1449
01:03:22,280 --> 01:03:27,080
The investment 500,000 to 1 million in year one for tooling implementation and training.

1450
01:03:27,080 --> 01:03:32,680
Year two and beyond 150 to 250,000 in maintenance and continuous improvement.

1451
01:03:32,680 --> 01:03:34,880
Payback period 6 to 12 months.

1452
01:03:34,880 --> 01:03:39,000
After that, pure benefit, but the financial case is half the story.

1453
01:03:39,000 --> 01:03:41,800
The implementation roadmap, how to get from here to there.

1454
01:03:41,800 --> 01:03:43,520
Knowing what to build is one thing.

1455
01:03:43,520 --> 01:03:45,240
Actually building it is something else entirely.

1456
01:03:45,240 --> 01:03:49,800
The transformation from siloed identity governance to unified AI governance isn't a feature

1457
01:03:49,800 --> 01:03:51,480
deployment that happens in a sprint.

1458
01:03:51,480 --> 01:03:54,440
It's an organizational shift that unfolds across quarters.

1459
01:03:54,440 --> 01:03:56,640
The roadmap that follows isn't theoretical.

1460
01:03:56,640 --> 01:04:00,360
It's based on how organizations that have executed this successfully actually staged their

1461
01:04:00,360 --> 01:04:01,360
work.

1462
01:04:01,360 --> 01:04:04,400
Start with foundation, spanning months, one through three.

1463
01:04:04,400 --> 01:04:07,600
During this phase, you're establishing the structural prerequisites.

1464
01:04:07,600 --> 01:04:12,080
All your cross-functional team, the people we discussed earlier, identity architects, security

1465
01:04:12,080 --> 01:04:16,000
engineers, compliance officers, data stewards and business stakeholders.

1466
01:04:16,000 --> 01:04:18,160
They need to meet weekly, they need shared goals.

1467
01:04:18,160 --> 01:04:20,080
Their first task is honest assessment.

1468
01:04:20,080 --> 01:04:22,480
How many agents exist in your environment right now?

1469
01:04:22,480 --> 01:04:24,040
How are they currently governed?

1470
01:04:24,040 --> 01:04:25,040
Where are the gaps?

1471
01:04:25,040 --> 01:04:29,960
This assessment surfaces shadow agents, unmanaged service principles and policy inconsistencies.

1472
01:04:29,960 --> 01:04:33,200
You're not trying to fix everything in this phase and you're trying to see clearly

1473
01:04:33,200 --> 01:04:36,600
as visibility improves, define organizational policy.

1474
01:04:36,600 --> 01:04:37,960
What should agents be allowed to do?

1475
01:04:37,960 --> 01:04:38,960
What's off limits?

1476
01:04:38,960 --> 01:04:40,480
Which data domains are sensitive?

1477
01:04:40,480 --> 01:04:41,960
What approval processes make sense?

1478
01:04:41,960 --> 01:04:44,600
This isn't documented in a share point site that nobody reads.

1479
01:04:44,600 --> 01:04:47,760
It's translated directly into Blueprints, design your initial three to five Blueprints

1480
01:04:47,760 --> 01:04:49,200
covering the risk tiers.

1481
01:04:49,200 --> 01:04:54,440
Low-risk read-only agents, medium-risk operational agents and high-risk data access agents.

1482
01:04:54,440 --> 01:04:56,960
Simultaneously, stand up the technical foundation.

1483
01:04:56,960 --> 01:04:58,440
Enable EntraEgent ID.

1484
01:04:58,440 --> 01:05:00,440
Configure conditional access for agents.

1485
01:05:00,440 --> 01:05:01,960
Set up your agent registry.

1486
01:05:01,960 --> 01:05:03,600
Get logging flowing to your CM.

1487
01:05:03,600 --> 01:05:06,520
This foundation work sounds administrative, but it's critical.

1488
01:05:06,520 --> 01:05:10,000
You can't operate a governance model without the infrastructure that enforces and observes

1489
01:05:10,000 --> 01:05:11,000
it.

1490
01:05:11,000 --> 01:05:13,000
The pilot phase runs months four through six.

1491
01:05:13,000 --> 01:05:15,760
You're now testing your designs in a controlled environment.

1492
01:05:15,760 --> 01:05:18,400
Identify five to ten agents already running in your environment.

1493
01:05:18,400 --> 01:05:20,640
A mix of official and shadow agents.

1494
01:05:20,640 --> 01:05:22,480
Migrate them into your new model.

1495
01:05:22,480 --> 01:05:23,960
Register them in the agent registry.

1496
01:05:23,960 --> 01:05:25,320
Assign them to Blueprints.

1497
01:05:25,320 --> 01:05:26,840
Apply conditional access policies.

1498
01:05:26,840 --> 01:05:27,840
Monitor what happens.

1499
01:05:27,840 --> 01:05:29,320
Do your Blueprints actually work?

1500
01:05:29,320 --> 01:05:31,800
Are the permissions scopes right or do you need to adjust?

1501
01:05:31,800 --> 01:05:33,040
Test your approval workflows.

1502
01:05:33,040 --> 01:05:35,920
Are they blocking legitimate work or are they too permissive?

1503
01:05:35,920 --> 01:05:38,800
Can you actually detect anomalies with your monitoring rules?

1504
01:05:38,800 --> 01:05:41,000
Gather feedback from the teams using these agents.

1505
01:05:41,000 --> 01:05:42,000
What's painful?

1506
01:05:42,000 --> 01:05:43,000
What's working?

1507
01:05:43,000 --> 01:05:44,000
What did you miss?

1508
01:05:44,000 --> 01:05:45,000
This phase builds confidence.

1509
01:05:45,000 --> 01:05:47,200
You're not betting the organization on an untested model.

1510
01:05:47,200 --> 01:05:49,640
You're proving it works in a limited context.

1511
01:05:49,640 --> 01:05:52,360
The pilot agents become your proof points when you expand.

1512
01:05:52,360 --> 01:05:55,360
The rollout phase covers months seven through twelve.

1513
01:05:55,360 --> 01:05:57,680
You're now migrating all agents into the new model.

1514
01:05:57,680 --> 01:06:00,280
This isn't rapid because you need to maintain stability.

1515
01:06:00,280 --> 01:06:02,040
You onboard existing agents in waves.

1516
01:06:02,040 --> 01:06:05,200
You simultaneously run shadow AI discovery at scale.

1517
01:06:05,200 --> 01:06:07,200
You can't stop the search for the new model.

1518
01:06:07,200 --> 01:06:09,200
You can't stop the search for the new model.

1519
01:06:09,200 --> 01:06:11,200
You can't stop the search for the new model.

1520
01:06:11,200 --> 01:06:13,200
You can't stop the search for the new model.

1521
01:06:13,200 --> 01:06:15,200
You can't stop the search for the new model.

1522
01:06:15,200 --> 01:06:17,200
You can't stop the search for the new model.

1523
01:06:17,200 --> 01:06:19,200
You can't stop the search for the new model.

1524
01:06:19,200 --> 01:06:21,200
You can't stop the search for the new model.

1525
01:06:21,200 --> 01:06:23,200
You can't stop the search for the new model.

1526
01:06:23,200 --> 01:06:25,200
You can't stop the search for the new model.

1527
01:06:25,200 --> 01:06:27,200
You can't stop the search for the new model.

1528
01:06:27,200 --> 01:06:29,200
You can't stop the search for the new model.

1529
01:06:29,200 --> 01:06:31,200
You can't stop the search for the new model.

1530
01:06:31,200 --> 01:06:33,200
You can't stop the search for the new model.

1531
01:06:33,200 --> 01:06:34,200
You can't stop the search for the new model.

1532
01:06:34,200 --> 01:06:36,200
The optimization phase begins around month 13

1533
01:06:36,200 --> 01:06:38,200
and continues indefinitely.

1534
01:06:38,200 --> 01:06:40,200
You're now operating the governance model at scale

1535
01:06:40,200 --> 01:06:42,200
but you're not done evolving.

1536
01:06:42,200 --> 01:06:44,200
Monitor the metrics that matter.

1537
01:06:44,200 --> 01:06:46,200
Are agents being approved and deployed faster than before or slower?

1538
01:06:46,200 --> 01:06:49,200
What percentage follow the fast path versus needing custom review?

1539
01:06:49,200 --> 01:06:51,200
Has your incident rate dropped?

1540
01:06:51,200 --> 01:06:53,200
Is agent adoption accelerating?

1541
01:06:53,200 --> 01:06:55,200
Use these signals to refine your blueprints.

1542
01:06:55,200 --> 01:06:57,200
If you keep modifying the same blueprint,

1543
01:06:57,200 --> 01:06:58,200
maybe it's not quite right.

1544
01:06:58,200 --> 01:07:00,200
Expand to multi-cloud.

1545
01:07:00,200 --> 01:07:02,200
If agents are running in AWS or Google,

1546
01:07:02,200 --> 01:07:04,200
sync them into your agent registry,

1547
01:07:04,200 --> 01:07:06,200
apply anthropologies across platforms,

1548
01:07:06,200 --> 01:07:09,200
make governance organizational, not cloud-specific.

1549
01:07:09,200 --> 01:07:12,200
The investment required isn't trivial but it's predictable.

1550
01:07:12,200 --> 01:07:15,200
Tooling and licenses 100 to 200,000 in year one.

1551
01:07:15,200 --> 01:07:18,200
Personnel, one full-time identity architect,

1552
01:07:18,200 --> 01:07:20,200
half-time security engineer,

1553
01:07:20,200 --> 01:07:22,200
half-time compliance officer,

1554
01:07:22,200 --> 01:07:23,200
training and change management.

1555
01:07:23,200 --> 01:07:25,200
50 to 100,000.

1556
01:07:25,200 --> 01:07:27,200
Year two and beyond drops to maintenance costs,

1557
01:07:27,200 --> 01:07:30,200
150 to 250,000 annually.

1558
01:07:30,200 --> 01:07:32,200
Success criteria are clear.

1559
01:07:32,200 --> 01:07:34,200
100% of agents known and governed.

1560
01:07:34,200 --> 01:07:37,200
80% of new agents following the faster approval path,

1561
01:07:37,200 --> 01:07:39,200
incident response time under one hour,

1562
01:07:39,200 --> 01:07:42,200
an accelerating agent adoption as the bottleneck dissolves.

1563
01:07:42,200 --> 01:07:44,200
The future state, where this is heading.

1564
01:07:44,200 --> 01:07:47,200
What is happening in your company right now is happening everywhere.

1565
01:07:47,200 --> 01:07:50,200
It isn't happening because Microsoft or AWS are pushing it.

1566
01:07:50,200 --> 01:07:52,200
It's happening because the market is demanding it.

1567
01:07:52,200 --> 01:07:56,200
Autonomous agents are multiplying faster than your governance can keep up.

1568
01:07:56,200 --> 01:07:58,200
And here is the shift within 18 months,

1569
01:07:58,200 --> 01:08:01,200
the companies that build identity frameworks for their agents

1570
01:08:01,200 --> 01:08:03,200
will move three times faster than everyone else.

1571
01:08:03,200 --> 01:08:05,200
If you are still treating agents like service accounts,

1572
01:08:05,200 --> 01:08:06,200
you are falling behind.

1573
01:08:06,200 --> 01:08:07,200
This isn't a guess.

1574
01:08:07,200 --> 01:08:11,200
It's a pattern we are already seeing in every enterprise that has committed to the model.

1575
01:08:11,200 --> 01:08:12,200
The trends are obvious if you look.

1576
01:08:12,200 --> 01:08:14,200
Agents are becoming ubiquitous.

1577
01:08:14,200 --> 01:08:18,200
They are embedded in every process, every workflow, every decision.

1578
01:08:18,200 --> 01:08:21,200
They are becoming more autonomous as the models get better.

1579
01:08:21,200 --> 01:08:23,200
And the need for a human in the loop disappears.

1580
01:08:23,200 --> 01:08:26,200
They are becoming interconnected, agent calling agent.

1581
01:08:26,200 --> 01:08:29,200
Orca-strating complex workflows that jump across systems and companies.

1582
01:08:29,200 --> 01:08:31,200
They are becoming more powerful.

1583
01:08:31,200 --> 01:08:32,200
Access is expanding.

1584
01:08:32,200 --> 01:08:34,200
Capabilities are deepening.

1585
01:08:34,200 --> 01:08:35,200
The stakes are rising.

1586
01:08:35,200 --> 01:08:38,200
But as that power grows, governance stops being optional.

1587
01:08:38,200 --> 01:08:39,200
It becomes existential.

1588
01:08:39,200 --> 01:08:43,200
You cannot scale autonomous agents without strong identity and policy controls.

1589
01:08:43,200 --> 01:08:47,200
Companies that try to skip this, that deploy agents with zero governance.

1590
01:08:47,200 --> 01:08:48,200
We'll find out the hard way.

1591
01:08:48,200 --> 01:08:51,200
A compromised agent steals sensitive data at scale.

1592
01:08:51,200 --> 01:08:54,200
A workforce agent makes a decision that violates compliance.

1593
01:08:54,200 --> 01:08:58,200
One agent makes an error and it ripples through every dependent system you own.

1594
01:08:58,200 --> 01:09:00,200
These incidents will happen.

1595
01:09:00,200 --> 01:09:05,200
The only question is whether your governance framework catches them before they break your business.

1596
01:09:05,200 --> 01:09:07,200
The technical direction is already converging.

1597
01:09:07,200 --> 01:09:09,200
Agent ID is becoming the standard.

1598
01:09:09,200 --> 01:09:10,200
This isn't just a Microsoft thing.

1599
01:09:10,200 --> 01:09:11,200
It's an architectural pattern.

1600
01:09:11,200 --> 01:09:14,200
The whole industry is adopting. AWS is building agent blueprints.

1601
01:09:14,200 --> 01:09:16,200
Google is implementing the same patterns.

1602
01:09:16,200 --> 01:09:19,200
The industry is finally admitting that AI agents need first-class identity.

1603
01:09:19,200 --> 01:09:22,200
Not service principles pretending to be something else.

1604
01:09:22,200 --> 01:09:25,200
Blueprints are becoming the standard way to write policy.

1605
01:09:25,200 --> 01:09:29,200
Multi-cloud governance is now a requirement because nobody stays on a single cloud anymore.

1606
01:09:29,200 --> 01:09:34,200
AI aware policy engines are moving from a nice to have to a baseline security requirement.

1607
01:09:34,200 --> 01:09:37,200
This shift isn't happening because vendors want to sell it.

1608
01:09:37,200 --> 01:09:39,200
It's happening because customers are demanding it.

1609
01:09:39,200 --> 01:09:41,200
The organizational direction is just as clear.

1610
01:09:41,200 --> 01:09:44,200
Agent governance is now a sea level responsibility.

1611
01:09:44,200 --> 01:09:47,200
Bords are asking how you govern AI the same way they ask about cybersecurity.

1612
01:09:47,200 --> 01:09:51,200
Regulations are coming and the AI act in Europe is just the beginning.

1613
01:09:51,200 --> 01:09:54,200
Other countries will follow and compliance will become non-negotiable.

1614
01:09:54,200 --> 01:09:59,200
Companies are building centers of excellence for AI governance because ad hoc approaches don't scale.

1615
01:09:59,200 --> 01:10:03,200
These teams are expensive to build but the cost of ignoring them is much higher.

1616
01:10:03,200 --> 01:10:06,200
The competitive advantage belongs to the people who master this early.

1617
01:10:06,200 --> 01:10:09,200
The scale AI faster because governance lets them move.

1618
01:10:09,200 --> 01:10:10,200
It doesn't block them.

1619
01:10:10,200 --> 01:10:14,200
They innovate faster because clear policies make approvals happen in days instead of months.

1620
01:10:14,200 --> 01:10:17,200
They take bigger risks because their controls are transparent.

1621
01:10:17,200 --> 01:10:22,200
They win customers because people trust companies that actually have control over their autonomous systems.

1622
01:10:22,200 --> 01:10:24,200
This isn't about checking a box for compliance.

1623
01:10:24,200 --> 01:10:27,200
It's about unlocking the potential of AI at scale.

1624
01:10:27,200 --> 01:10:31,200
You cannot deploy thousands of agents without a foundation that makes that scale safe.

1625
01:10:31,200 --> 01:10:35,200
The organizations that build that foundation today will be in a different league tomorrow.

1626
01:10:35,200 --> 01:10:38,200
You started by treating agents like service accounts.

1627
01:10:38,200 --> 01:10:40,200
It was a bridge from the old model.

1628
01:10:40,200 --> 01:10:44,200
And it worked for a while but that bridge is collapsing under the weight of what agents have become.

1629
01:10:44,200 --> 01:10:48,200
Entra agent ID isn't just a feature. It's a structural necessity.

1630
01:10:48,200 --> 01:10:51,200
Blueprints aren't bureaucracy. They are how you scale.

1631
01:10:51,200 --> 01:10:53,200
The agentic fabric isn't a Microsoft product.

1632
01:10:53,200 --> 01:10:55,200
It's the operating model for the future of work.

1633
01:10:55,200 --> 01:10:57,200
The question isn't whether you should build this.

1634
01:10:57,200 --> 01:10:59,200
It's how fast you can get it done. Start now.

1635
01:10:59,200 --> 01:11:02,200
Assess your current state. Design your blueprints.

1636
01:11:02,200 --> 01:11:06,200
Build your processes. The organizations that do this will lead.

1637
01:11:06,200 --> 01:11:08,200
The others will spend the next decade trying to catch up.

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.