AI agents are reshaping enterprise operations. They reason over data, call APIs, trigger workflows, and act on behalf of users — often without human intervention. IDC projects 1.3 billion AI agents in production by 2028, and Capgemini research shows four out of five organizations plan to integrate agents within the next three years.
The race to build is already underway. The harder question — one most organizations are not yet equipped to answer — is: how do you operate AI agents safely at scale?
Deploying a demo-ready agent is table stakes. Making that same agent production-grade, with proper identity, access controls, governance, and runtime protections, is an entirely different engineering and operational challenge.
Why agentic AI changes the security equation
Traditional software executes deterministic logic. An AI agent reasons, plans, and takes action — dynamically, across systems it was never explicitly programmed to touch. When connected to enterprise APIs and data, an agent stops being a chatbot and starts functioning as a digital worker.
That shift has direct security implications:
- Agents can trigger business processes and access sensitive data autonomously
- Their capabilities expand as new tools and Model Context Protocol (MCP) servers are connected
- They behave non-deterministically, making static policy controls insufficient
- A compromised or misconfigured agent can have a large blast radius
Most organizations are deploying into this environment without the governance infrastructure to match. The result is growing agent sprawl, unclear accountability, and unmanaged risk — exactly the conditions that security and compliance teams lose sleep over.
A three-pillar framework for secure agent operations
Securing AI agents at enterprise scale requires a structured approach. The following three-pillar framework provides a practical foundation: Manage, Govern, and Protect.
Pillar 1: Manage — build an agent registry and enforce identity
The first pillar focuses on visibility. You cannot secure what you cannot see, and you cannot control what you cannot identify.
Every agent in your environment must have a unique, managed identity — a first-class identity type distinct from human accounts, service principals, and workload identities. Without it, agents are anonymous automation: untraceable, un-auditable, and uncontrollable.
With agent identity in place, organizations gain:
- Traceability — a full record of what each agent accessed, when, and in what context
- Auditability — the clean audit trail that security and compliance teams require
- Granular control — the ability to restrict, block, or revoke access based on policy
The operational target is an agent registry: a centralized fleet view of every agent across the organization, including those built on non-Microsoft platforms. Operators should be able to inspect agent metadata, validate ownership, review configuration, and block agents directly from this registry.
This fleet management capability is what separates enterprise-grade deployments from uncontrolled agent sprawl.
Pillar 2: Govern — automate agent lifecycle management
The second pillar addresses the operational reality that emerges once agents number in the hundreds or thousands: manual governance doesn't scale.
Three foundational practices make lifecycle governance work at scale.
- Assign a sponsor to every agent
Each agent must have a designated owner — a person or team accountable for its activity and access decisions from creation through retirement. Orphaned agents, where no human is accountable, represent a high-risk surface area. Sponsorship creates a clear chain of accountability that also supports incident response when something goes wrong. - Automate lifecycle policies
Agents change hands, move between teams, and eventually retire. Access granted at creation may be inappropriate six months later. Lifecycle policies — covering creation, handoff, access review, and decommissioning — must be automated to remain effective at scale. The goal is to remove routine human intervention from the process while ensuring every action is logged and auditable. - Enforce just-in-time, time-bound access
Agents should never hold standing permissions. Access should be intentionally scoped, time-limited, and removed when no longer required. This directly addresses permission accumulation — one of the most common and underappreciated risks in agentic deployments, where an agent gradually gains access to resources far beyond its original purpose.
The full lifecycle flow runs from creation (sponsor assigned, access requested and approved) through active operation (periodic access reviews) to retirement (identity deleted, access expired). Every stage should generate an auditable record.
Pillar 3: Protect — secure agents at runtime
The third pillar covers production runtime security — what happens once agents are live and actively accessing corporate resources. This is where risk is most dynamic and where a defense-in-depth approach is non-negotiable.
Agents require access to file stores, APIs, calendars, MCP servers, and third-party SaaS systems to deliver value. Each of those connections is also an exposure point for prompt injection, data exfiltration, or access to malicious content.
Three mechanisms form the runtime protection stack.
- Conditional access policies for agents
The same conditional access framework used for human identities can be applied to agents — enforcing policy based on agent identity and operating context. This enables broad baseline protections across the entire agent fleet, with stricter controls for high-impact agents or sensitive scenarios. Access decisions happen continuously and automatically, not as one-off reviews. - Risk signal detection and automated response
Risky agent behaviors — sudden access spikes, repeated resource access failures, or attempts to reach unfamiliar systems — generate signals that can trigger automated responses. Policies can block the agent, limit its blast radius, and alert security operations for investigation, all without manual intervention. - Network-layer controls
Identity and access controls alone are not sufficient. Content inspection, threat-intelligence-based URL filtering, and file-level network filtering add additional layers of protection, particularly against agents that interact with external systems or user-supplied inputs. No single control point should be relied upon exclusively.
Understanding agent blueprints and identity hierarchy
One of the most important architectural concepts for enterprise agent governance is the distinction between an agent blueprint and an agent identity.
An agent blueprint is a reusable, tenant-scoped template that defines the security, authentication, and governance characteristics for a class of agents. It sets the operational boundary: what the agent is allowed to do, which resources it can access, and which policies govern its behavior.
An agent identity is a specific instance derived from a blueprint. One blueprint can generate many identities, each inheriting the governance constraints defined in the template.
This parent-child model delivers concrete benefits across roles:
- Developers get a predictable, consistent identity model for every agent they build
- IT and security teams gain class-level audit trails and lifecycle control without per-instance overhead
- End users and customers can trust that every agent instance operates within the boundaries set at design time
Governance intent — authentication, authorization, execution boundaries — is defined once and applied consistently across the entire agent family derived from that blueprint.
MCP tool governance: Managing agent interoperability
Modern agents rarely operate in isolation. They connect to external tools and services through protocols like MCP (Model Context Protocol), enabling tasks like retrieving documents from SharePoint, sending email, scheduling meetings, and coordinating with other agents.
The power of this connectivity is real. A single agent instruction can simultaneously invoke multiple MCP servers — retrieving a file, generating a shareable link, sending it via email, and creating a calendar event — all in one natural-language-triggered flow.
That same power is also a governance surface. Not every available MCP tool is appropriate for every agent, and not every tool is safe for production use without review.
The right approach is to treat tool access like data access: intentional, reviewed, and tied to the agent's identity. Access to specific MCP servers should be formally requested, approved by IT or security, and documented as part of the agent onboarding process — not left to developer discretion at build time.
Five practices for production-ready agent security
The framework above translates into concrete practices for teams building and operating agents today.
- Build identity in, not on.
Retrofitting governance onto an existing agent fleet is significantly harder than starting with identity baked into the build process. Every new agent should have an identity, a sponsor, and a defined access scope before it ships. - Design for the fleet, not the agent.
The practices and templates you establish for one agent should scale to hundreds. Reusable blueprints, automated lifecycle policies, and standardized onboarding patterns are investments that compound as agent counts grow. - Threat-model before you deploy.
For each production agent, work through what data it can access, what actions it can take, what happens under a malicious prompt, and what the blast radius looks like if it is compromised. Threat modeling surfaces risks that capability-focused development naturally misses. - Automate governance alongside capability.
The instinct in AI development is to automate what the agent does. Apply that same instinct to how the agent is governed. Lifecycle policies, access reviews, risk signal responses, and audit log generation should all run without manual orchestration. - Apply zero trust to agents explicitly.
Least privilege, continuous verification, and assume-breach principles apply to agents just as they do to humans and workloads. Agents that accumulate permissions over time, or that operate without continuous policy enforcement, are a liability as the threat landscape evolves.
Distributing governed agents through Microsoft Marketplace
The governance architecture described in this post — Entra agent identity, blueprints, lifecycle policies, and zero trust controls — applies equally to software development companies distributing agents through Microsoft Marketplace. These constructs are what determine whether a third-party agent can be trusted and managed by the enterprise customers who purchase it.
With Agent 365 now generally available, enterprise customers have a control plane for managing every agent in their Microsoft 365 tenant, including agents procured from Marketplace. A software company-built agent that arrives without a registered Entra agent identity will surface as unmanaged in the customer's registry, requiring manual remediation before it can be approved for use — a friction point that directly delays adoption.
For software company agents to pass enterprise IT and security review in an Agent 365-enabled tenant, three things must be in place from day one:
- Registered Entra agent identity — enables the customer to apply their own conditional access and lifecycle policies to the agent
- A well-defined agent blueprint — tells the customer's IT and security teams what the agent is permitted to do, what resources it accesses, and what governance characteristics it carries
- Declared and scoped MCP tool access — allows the customer's admin to review and approve tool permissions before the agent goes live
A software company agent that ships with these elements in place signals it was built for enterprise operations from the start — and that trust signal is increasingly what separates agents that clear procurement review from those that stall in it.
The competitive case for getting this right
Organizations that build secure, governed agent infrastructure do not just reduce risk — they accelerate adoption. When security and operations teams can trust the agents in their environment, the internal friction that slows deployment decreases. Partners and software companies that deliver governed, auditable agent solutions create durable differentiation compared to those shipping ungoverned agents into customer environments.
The companies winning in the agentic AI space are not just building agents. They are building the platform, practices, and governance infrastructure around them. That is what enterprise customers are increasingly requiring, and it is what separates a compelling demo from a production-grade solution.
The principles have not changed — identity, least privilege, auditability, and defense in depth. What has changed is that those principles now apply to a new class of actor in the enterprise: the AI agent.
View past and upcoming sessions in the Security for software development company series: Security for SDC Series: Securing the Agentic Era
Microsoft