Agentic GRC: How much authority should AI agents get?

Giving an AI agent access to a system is one thing. Letting it make decisions inside that system is another.

But here's where things get complicated: human approval isn't automatically safer, either.

An agent might act beyond its intended instructions. A human might approve something without reviewing it. And when something goes wrong, an audit log might show what happened without explaining why.

So how should security and Governance, Risk, and Compliance (GRC) leaders decide what AI agents can do, when humans need to intervene, and who ultimately owns the outcome?

That was the central discussion in Scrut's webinar, Agentic GRC: Building Trust Through Authority, Approval, and Accountability, featuring Justin M, Director of Compliance at DTEX; Ryan Schoeller, Director, Security GRC at Treasure AI; and Aditya Iyer, GRC Program Manager at Scrut Automation.

The panel explored three interconnected questions: How much authority should agents receive? Where should human approval remain? And who is accountable when an agent acts?

What emerged was a practical approach to governing AI agents, one that starts with understanding what is already happening inside the organization, rather than assuming governance can begin with a policy.

AI agents are already here. Governance is playing catch-up.

The conversation began with a familiar security challenge: employees adopting technology faster than organizations can govern it. Just as developers once brought personal GitHub accounts into the workplace, employees are now bringing their preferred AI tools and agents. And the more useful these tools become, the harder they are to restrict.

Justin acknowledged that agents tailored to individual workflows can deliver genuine value. 

That usefulness also makes it unrealistic to expect policies alone to control adoption.

Ryan highlighted what often happens when organizations remove an AI tool employees rely on. If the approved alternative doesn't meet their needs, employees may look elsewhere.

Shadow AI Governance doesn't necessarily disappear. It becomes harder to see. That's why Ryan advocated for a "yes, but" approach to AI adoption.

Instead of immediately rejecting new tools, GRC teams should examine whether the use case can move forward with appropriate controls, restrictions, or mitigating measures. The objective isn't to approve everything. The goal is to create a path for responsible adoption without pushing AI use outside the organization's visibility.

A quick game revealed a bigger governance problem

Before moving into the three pillars of the discussion, the panel played Scrut's Shadow AI Arcade.

Different applications appeared on screen, and the participants had to identify whether each was an AI application, an AI builder, or not AI at all. The exercise illustrated a challenge security teams increasingly face: identifying AI technology isn't always straightforward.

Try it yourself →

If identifying the tools is difficult, understanding what they can do matters even more. That led to the next question.

You've found the agent. Do you know what it can do?

Discovering an AI application tells you little about the risk it introduces.

An AI assistant that summarizes documents is fundamentally different from an agent that can modify code, update customer records, or execute actions inside connected systems.

Aditya emphasized that knowing which AI tools exist is only a fraction of the visibility GRC teams need.

For every agent, organizations should understand:

• Tool: Which application or agent is running, and is it approved?
• Owner: Which employee or team is responsible for it?
• Data: What information and systems can it access?
• Actions: What can it create, modify, delete, or execute independently?
• Connections: Which integrations or Model Context Protocol (MCP) servers extend its reach?

These details matter because agents don't simply consume information. They can interact with the environments they're connected to.

An agent might be introduced to perform one narrow task, but its permissions and integrations could let it do far more. Without visibility into those execution boundaries, organizations can't accurately assess its authority or the risks that come with it.

The lesson: Shadow AI discovery answers what exists. Agent governance must answer what those tools can actually do.

And once those capabilities are understood, the next decision becomes unavoidable: how much authority should an agent receive?

Your agent doesn't need the keys to everything.

Justin's answer to the authority question began with least privilege. An agent should never have more access than the person it represents. Ideally, it should have only the permissions necessary to perform its assigned task.

For example, an employee without access to modify a code repository shouldn't be able to deploy an agent that can make those changes on their behalf.

But permissions alone aren't enough.

The panel discussed treating agents like identities that need lifecycle governance.

That includes:

• Onboarding and offboarding agents through defined processes.
• Maintaining an approved inventory of agents.
• Using naming conventions that distinguish agent activity from human activity.
• Assigning a clear human owner to each agent.
• Applying change management processes when agents modify systems or data.

Justin also raised a question organizations should ask before deploying agents: Are we testing what they're capable of doing enough?

Instructions and steering files can define expected behavior, but they don't guarantee an agent will remain within those boundaries.

Before granting meaningful authority, organizations need to test what an agent can access, change, and produce. The existing security practices such as least privilege, identity management, testing, and change control remain relevant. The challenge is applying them to systems that can act autonomously.

The lesson: Give agents the minimum authority required for their work, then verify that they operate within those boundaries.

But even a carefully permissioned agent will eventually encounter decisions that require judgment.

Should it make those decisions independently? Or should a human always step in?

Is human approval really the safety net we think it is?

This was one of the webinar's most interesting points, and the panelists approached it differently.

Ryan challenged the assumption that human approval automatically makes a decision safer.

Two people reviewing the same information can reach different conclusions. Even experienced professionals make inconsistent decisions, particularly when handling large volumes of repetitive work.

So instead of treating every human approval as essential, Ryan suggested looking at two factors.

First, can the decision be undone?

An incorrectly closed ticket can be reopened.

A production change that causes significant disruption, or the release of sensitive intellectual property, may be much harder to reverse.

The more difficult an action is to undo, the stronger the case for human intervention.

Second, did human judgment actually change previous outcomes?

Ryan suggested examining historical GRC decisions to identify where human review genuinely adds value.

Consider a team reviewing third-party SOC 2 reports or evaluating risk exceptions.

How often did reviewers reject something? When they did, did that decision materially change the outcome? How many approvals were effectively routine?

If the historical evidence shows that a particular review step rarely changes outcomes, that step may be a candidate for agent assistance or controlled automation.

The important distinction is between automating a specific decision and handing over an entire workflow.

Justin offered a more cautious perspective.

Having seen agents ignore steering files and drift beyond their intended instructions, he argued that final or irreversible actions should continue to require human review.

Together, the two perspectives offer a more practical decision framework.

Use historical evidence to identify where automation may be valuable, while preserving human control over actions with significant or irreversible consequences.

The lesson: Don't add human approvals simply because AI is involved. Keep them where judgment genuinely reduces risk.

Of course, retaining human approval introduces another challenge: what happens when approvals become routine?

Human in the loop isn't much help if they just "approve."

A human approval checkpoint looks reassuring on paper.

But if a reviewer receives dozens of routine requests and clicks through without examining them, is the organization actually exercising meaningful oversight?

The panel highlighted how approval fatigue can weaken the very controls intended to manage risk.

A meaningful approval process requires three things:

• Enough context to decide: The reviewer understands what the agent wants to do, why, and which systems or data could be affected.
• A manageable volume of decisions: Reserve human attention for actions where judgment matters.
• A genuine ability to intervene: The reviewer can reject or stop the proposed action, not merely acknowledge it.

Ryan's approach to historical decision analysis becomes particularly relevant here.

By identifying which approvals have made a notable difference in the past, organizations can reduce unnecessary review while retaining oversight of consequential actions.

Justin's perspective reinforces another important point: human approval shouldn't compensate for inadequate agent testing or excessive permissions.

The objective isn't to maximize human checkpoints. It's to ensure the checkpoints that remain actually work.

The lesson: Measure whether human approvals improve decisions, not simply whether someone clicked a button.

But even with the right permissions and approvals, things can go wrong.

And when they do, organizations need to answer a different set of questions.

The audit log says what happened. Can it explain why?

Traditional system logs can show that a file changed, a record updated, or an API request executed.

With autonomous agents, that information may not be sufficient.

Aditya highlighted a fundamental auditability problem: an organization must be able to explain why an agent made a decision, not just prove that an action occurred.

He proposed capturing three elements.

• Context: What information did the agent have when it acted?
• Rule: Which policy, instruction, or decision rule justified the action?
• Integrity: Can the organization demonstrate that the record wasn't modified afterward?

When human approval was required, the record should also include that decision.

Together, these elements provide a more complete explanation of how an agent moved from an instruction to an outcome.

But Ryan introduced another challenge: attribution.

When an employee connects an agent to another system using existing credentials or integrations, downstream logs may record the agent's actions under the employee's identity.

The system can show whose credentials were used, but not necessarily whether the person or the agent performed the action.

That leaves security and GRC teams with two distinct questions.

Can we explain the decision?

What did the agent know, and what rule guided its behavior?

Can we attribute the action?

Was the action performed directly by an employee, or by an autonomous agent operating through that person's access?

Justin also discussed the importance of integrating agent activity into existing monitoring systems, including security information and event management (SIEM) platforms and dashboards.

Without that visibility, investigating unexpected agent behavior becomes much harder.

The lesson: Logging what an agent did is only half the job. Organizations also need to understand why it acted and distinguish the agent's activity from its human owner's.

Which brings us to the final, and perhaps most consequential question.

When an agent gets it wrong, who owns the mistake?

Consider an agent that operates within its approved permissions, follows the assigned workflow, and still makes the wrong decision.

Who is accountable?

Aditya argued that responsibility remains with the people who configured the agent and set its guardrails. Agents don't independently decide what permissions they should receive. People define their instructions, approve access, set boundaries, and determine how they're monitored.

The panel's closing discussion extended accountability to each of those choices.

Who wrote the steering file? Who configured the agent? Who approved its permissions? Who was responsible for monitoring it?

Those responsibilities shouldn't disappear simply because the agent executed the final action. And operating within approved permissions doesn't automatically make an outcome acceptable. If an agent makes an incorrect decision inside its assigned boundaries, the organization still needs to investigate whether its instructions, validation processes, or guardrails were adequate.

The lesson: Autonomy can change who performs an action. It doesn't transfer accountability away from the people responsible for the agent.

So, where should we draw the line?

The webinar ended with two questions: What decisions must always remain human, and where shouldn't AI be involved at all?

Justin drew a clear boundary around final or irreversible actions, particularly those affecting products or potentially exposing intellectual property. A mistakenly closed ticket can be reopened. Sensitive information released outside the organization may be impossible to recover.

Ryan introduced an important distinction. Using generative AI to support a task isn't the same as deploying an autonomous agent to execute it.

An organization might use AI to summarize evidence or prepare an assessment without allowing an agent to make the final decision. Across his GRC program, Ryan could see potential uses for agent assistance in many processes, while recognizing that some experiments might not work.

The panel didn't arrive at a universal rule for where AI should or shouldn't operate.

Instead, the discussion suggested a more useful approach: determine what authority is necessary, assess the consequences of failure, identify where human judgment adds value, and ensure that decisions remain traceable and accountable.

The goal isn't maximum autonomy. It's autonomy you can trust.

Agentic GRC isn't about allowing AI agents to do everything humans currently do.

It's about enabling agents to reduce repetitive work without losing control over risk, oversight, or accountability. That means moving beyond discovering AI applications and writing acceptable-use policies.

Security and GRC teams need to know what agents can execute, which actions require approval, and how to preserve decision-making evidence.

Five questions to ask before giving an agent authority

Choose three AI agents or agent-enabled workflows already operating in your organization.

For each, ask:

1. Authority: What can the agent read, modify, or execute? Are those permissions necessary for its task?
2. Reversibility: Which actions could cause damage that's difficult or impossible to undo?
3. Approval: Where does a human intervene, and does that person have enough context to make an informed decision?
4. Auditability: If the agent made a mistake tomorrow, could we explain what information it used, which rule it followed, and who authorized the action?
5. Accountability: Who owns the agent, its configuration, and its outcomes?

The answers should lead to concrete decisions: retain existing authority, narrow permissions, introduce an approval step, strengthen monitoring, or pause execution until risks are addressed.

Because the real question isn't simply whether an agent can do something.

It's whether the organization can trust, control, and explain what happens when it does.

Check out the full conversation on Agentic GRC

These takeaways capture the central themes, but the full webinar goes deeper into where experienced GRC practitioners differ on human oversight, how historical decisions can inform automation, and what accountability looks like when an agent follows the rules but still makes the wrong call.

Hear Justin, Ryan, and Aditya discuss how organizations can balance AI autonomy with effective governance.

Watch the Agentic GRC Webinar On Demand →

The conversation doesn't stop here. Join our next live webinar, The AI Governance Reality Check: What Are Companies Getting Wrong?, on November 19 at 12:00 PM ET, as we examine where AI policies fall short of real-world usage and which governance gaps organizations need to address first.

Register now for the Next Webinar →