Over this past year, we have worked closely with customers as their agents executed transactions across finance, procurement, and customer service, and as their employees handed multi-step work to agentic tools connected to their systems of record. In our early conversations, security leaders wanted to discuss data exposure in prompts, prompt injection, and jailbreaks. Those risks have not gone away, and our customers continue to invest in detecting them. As their deployments matured, however, the conversations changed. The risks customers brought to us were financial, operational, compliance, and safety risks, and they were the same problems their organizations had spent years writing policies to prevent.
One of the clearest examples came from a banking customer. The bank's governance prohibited employees from interacting with gambling content, and its security team enforced that rule the way security teams always have, by shutting down network access to gambling websites. That control worked as intended for employees browsing the web. However, employees using AI tools and agents could still access the same gambling information through those tools, and the network block never saw those requests because the AI tool retrieved the content on the employee's behalf. The governance rule still applied, and AI had opened a path to restricted information that the security team's controls were never designed to cover.
We heard similar accounts from other customers. AI tools given to employees could be used to commit fraud against the company, and in more serious cases, to cause safety harm to colleagues. None of these cases resembled data exfiltration, prompt injection, or a jailbreak. Each one violated a rule the organization had already written into a finance policy, an acceptable use policy, or a code of conduct.
Those conversations have guided how we approach AI governance. The organizations we work with have no shortage of business governance. They have spent decades defining what requires approval, what information is restricted, and what conduct is prohibited. What they lack is a way to apply that governance to the actions AI takes on their behalf, at the moment those actions occur. Applying it at that moment is what operationalizing AI governance requires, and the work falls to the security team, the same team that has always turned the organization's written rules into technical controls.
Enterprise Governance Was Written for People, and Its Controls Do Not Extend to AI
Enterprise governance was written for people. Approval thresholds sit in finance policies, data handling standards sit in compliance documents, and conduct expectations sit in employee handbooks. Organizations enforce them through training, management oversight, approval workflows built into business applications, and the technical controls security teams maintain, and each of those controls was designed for a person taking the action through the applications and networks the organization manages.
Agents change where business actions take place. An agent resolving a customer escalation may issue a refund in Stripe, update the case in Zendesk, and message the account team in Microsoft Teams from a single request. A procurement agent may query a vendor database, draft a purchase order, and submit a payment as steps in one task, and an employee working through an agentic tool can export hundreds of customer records with a single instruction. Each of those actions carries business consequences, and the rules that should govern them sit in documents with no connection to the tool calls where enforcement needs to happen.
The guardrails built into frontier models cannot enforce those rules. They are designed for general public use and have no knowledge of an individual enterprise's procurement rules, approval workflows, or code of conduct. A model can decline to produce content that would be harmful for any user, and it has no way to know that one company requires end-user approval for any payout above $5,000, or that another prohibits forwarding mail from a colleague's mailbox. Those rules belong to the enterprise, and only the enterprise can define them.
Security Teams Have Always Put Governance into Operation
Enterprise governance has long followed the same division of labor. HR, compliance, legal, and finance teams write the rules, and the security team enforces them, because security controls the infrastructure where those rules take effect. A rule against gambling content becomes web filtering on the network security stack, and a data handling standard becomes a DLP policy. Rules that never receive a technical control stay in a document, unenforced.
When we talk with security leaders about enforcing business policies for AI, some tell us it sounds like a governance problem that belongs to another team. We see it differently. Governance teams decide what the rules are, and the security team has always been the technical control that puts those rules into operation. AI requires that same control at runtime, and the security team is the one equipped to provide it, as it always has for the network and for sensitive data.
Putting governance into operation for AI depends on the same handoff between the teams that write the rules and the security team that enforces them, and those teams work in separate workflows. Connecting them has always depended on a manual translation step, in which someone reads a policy, interprets its intent, and converts it into templates, static rules, and hardcoded if/then statements for each system it governs.
That translation step breaks down as AI adoption scales. Every new AI tool and agent introduces new connections to enterprise systems, and a rule hardcoded for one system has to be rewritten for the next. When an acceptable use policy, a data handling standard, or an approval workflow changes, the update depends on tickets, manual rule rewrites, and agent redeployments before it takes effect. Because the policy and the control are maintained by different teams in different languages, governance teams have no direct way to verify that what is enforced matches what was written. Governance committees can recommend controls with no way to see them applied, and risk assessments happen separately from the systems they assess.
Our own research reflects this disconnect. In Proofpoint's 2026 AI and Human Risk Landscape report, a survey of more than 1,400 security professionals, 76% of organizations were piloting or rolling out autonomous agents, yet 41% cited gaps in governance alignment across teams. We hear a related concern from security leaders once they see the full scope of AI activity in their environments. Their next question is who will act on it, and many of them tell us they don't have the staff. Operationalizing AI governance cannot depend on adding people to translate every policy into technical rules by hand.
Semantic Business Policies Turn Written Governance into Runtime Enforcement
In response to what we learned from our customers, we built Semantic Business Policies, which we introduced at Protect 2026, to give security teams the technical control for AI governance. Semantic Business Policies allow organizations to take their existing corporate governance and write new business rules in plain English, and have all of them enforced at runtime across employees and autonomous agents. Administrators write rules the way they would describe them to a colleague, or import the governance documents the organization already maintains, and each sentence is read as a rule, mapped to a capability, and resolved against the tools in the environment. Proofpoint AI Security interprets the business intent behind each rule, identifies the enterprise systems capable of carrying out the action, such as Stripe, ServiceNow, Jira, Zendesk, and Microsoft Teams, and generates the runtime controls to enforce it.
A restriction like the bank's becomes a single rule, "Do not allow interactions with gambling websites," which applies to the AI tools and agents capable of retrieving that content. A finance team can write "Never allow an outbound payout or transfer over $5,000 without end-user approval," and every payout an AI tool or agent initiates above that threshold pauses for approval while lower-value transactions proceed. Every governed action receives an Allow, Deny, Redact, or Ask decision, paired with parameter-level constraints such as dollar thresholds, record limits, date ranges, and required approver roles. A read capped at 100 records cannot become a bulk data export, and a purchase above a set threshold requires the right approver.
Semantic Business Policies bring AI security and governance together in a single operational workflow. Business rules are authored in the language the policy owner uses and enforced by the security team directly at runtime, with no translation step between the team that owns the rule and the controls that enforce it. When an approval workflow or a data handling standard changes, the policy is updated in minutes, and the change is enforced without rewriting code or redeploying agents. Every policy also has two synchronized views. Administrators work in the Policy Construct view, which shows the capabilities, decisions, constraints, and tool bindings behind each rule, while CISOs, auditors, and regulators review the same policy in the Plain English view. Changing one updates the other, so governance, compliance, and security teams work from the same policy, and the rule that was approved is the rule that is enforced.
The same policy governs employees and agents. Whether an employee acts through an agentic tool or an autonomous agent handles the same workflow, the business rule is identical, because the organization's expectations do not depend on who or what takes the action. Policies are saved at the organization level and enforced wherever the governed services are connected, so governance extends to every new AI tool and agent without per-agent configuration.
Governance Grows as New AI Risks Emerge
Semantic Business Policies establish the rules for what the enterprise has authorized, and Intent-Based Access Control (IBAC) continuously evaluates every agentic action against those rules and detects the moment behavior deviates from business intent. Written governance, however thorough, covers the risks an organization has already recognized. As AI adoption grows, new risks will emerge that no policy addresses, because no one has seen them before. Agentic Insights uses autonomous reasoning agents to analyze AI interactions, tool usage, policy decisions, and user and agent behavior to identify those new risks. When a risk is validated, administrators can turn it into a new Semantic Business Policy that Proofpoint AI Security enforces from that point forward. Defining policy, enforcing it at runtime, and discovering new risks become one continuous process, and the organization's governance grows with its AI adoption.
The Bottom Line
Every organization we work with already knows what it expects of its people. Those expectations are written into finance policies, compliance standards, codes of conduct, and acceptable use guidelines that represent decades of institutional knowledge about how the business should operate. Security teams have always been the ones who put those expectations into operation, and operationalizing AI governance extends that responsibility to every action AI takes on the organization's behalf. Semantic Business Policies give security teams the control to enforce that governance at runtime, and they give the people accountable for it a direct view of what is enforced. We will continue that work alongside our customers as their AI adoption grows.
To see how Semantic Business Policies convert written governance into runtime enforcement across employees and agents, watch our product walkthrough.