❮ Back to blog
AI Security

How Workday Thinks About AI Agent Governance

Workday's Director of Security Architecture shares how to secure AI agents without slowing innovation, detailing a four-step framework for scalable AI governance.

By Jason Popp, Director of Security Architecture, Workday
3 min read

Everything changed when AI assistants became AI agents. A tool that suggests code fixes is very different from an agent that can read a GitLab wiki, open a ServiceNow ticket, query a Databricks table, and commit code to GitHub on a user’s behalf.

As users automate more of their work with tools like Claude Code and Claude Cowork, the challenge for security is clear: how do you enable adoption without adding friction or compromising safety?

At Workday, we’re working through that challenge every day. My goal is to keep the business moving at the forefront of AI innovation while giving our security teams the visibility and controls they need to manage the risks that come with it.

What we're seeing on the ground

Agents don’t stay inside the terminal. To be useful, they connect to the systems where work actually happens, apps like Jira, Confluence, Salesforce, Tableau, and dozens of others employees rely on every day.

Every connection makes an agent more useful. It also expands what that agent can read, change, and act on. That becomes particularly important as agent access expands beyond experienced developers. 

When more employees can build and run agents, we can’t rely on individual judgment to determine whether an action is safe. Trust is important, but it isn’t a control. And it doesn’t scale to thousands of agent sessions.

We’re building toward a model where the right controls are built into the experience, where security becomes visible only when an agent is about to do something that requires intervention.

Security without friction

Our philosophy is simple: don’t impede the business. With AI, that means security can’t build and enforce new policies without understanding the impact.

To gather this evidence, we started with visibility. What agents exist? Who is using them? What systems do they connect to? What are they actually doing?

From there, we identified the behaviors that matter. Once we feel confident in our assessment, that is when security can move toward a more proactive posture. Enforcement comes when we have enough evidence to know what needs to be controlled.

When we were ready to take this step, I stressed to my team the importance of two things:

  • First, governance needs to be consistent. If every team creates its own approach to agent security, you quickly end up with fragmented controls and inconsistent risk decisions.
  • Second, documenting frameworks creates structure and accountability, turning a broad goal like “govern AI” into concrete commitments, owners, and timelines to track progress and success.

Getting started in four steps

  1. Right-size access before you scale. Agents often inherit the permissions of the users who run them. The problem is that those permissions may reflect years of accumulated access rather than what an agent actually needs to complete a task.

The more access and privilege an agent has, the larger its potential blast radius. Narrowing permissions to only what the work requires is one of the simplest ways to reduce risk before an incident happens.

  1. Put runtime guardrails where the stakes are highest. Not every agent action deserves the same level of scrutiny. An agent autonomously reading a Confluence page is very different from an agent modifying a production table. The key is understanding which actions carry meaningful consequences and deciding where a human needs to be in the loop.

Done well, these controls should be nearly invisible to users. The goal isn’t to interrupt every action. It’s to intervene when the stakes justify it.

  1. Monitor agent activity with streaming detections. The first two controls are strongest during setup and new agent reviews. But access and guardrails describe what agents can do. Just as important is what agents are doing.

That's why telemetry has to cover everywhere agents run. When an agent trips a defined risk factor, like executing a bash command it shouldn't, or writing outside its project scope, someone on the security team needs to be alerted. Continuous visibility is also how we confirm access is shrinking rather than accumulating, and that the guardrails fire when they should. Without it, right-sizing agent access is an intention, not a measurable fact.

  1. Govern the MCP layer. Model Context Protocol servers give agents access to new tools, data, and capabilities. They also introduce a new layer security needs to monitor.

At Workday, it was important we gain visibility into which servers exist, what they can access, who is using them, and whether they meet the organization’s security requirements.

How to make yes the default answer

Security teams have spent years being cast as the department of no. Agentic AI gives us an opportunity to change that. Visibility first. Evidence-based controls second. Governance that makes the safe path the easy path.

Get that right, and security doesn’t have to be the reason AI adoption slows down. It can be the reason the business has the confidence to move faster.

Frequently Asked Questions (FAQs)