Glean Agents in a Regulated Bank: How to Govern Them

Glean agents are AI workflows that read enterprise knowledge and take actions in connected systems. In a regulated bank, governing Glean agents means deciding who can build them, whose identity they run as, which tools they can use without a human, and what evidence they leave. Our view at HRTG: the defaults are a starting point, not a control framework.

Glean gives banks real governance controls for agents. Most of them are settings an admin has to choose deliberately. This guide maps those settings to the questions a bank's risk, security, and audit teams will ask.

What are Glean agents?

Glean agents run in two modes. In Auto mode, a builder describes the outcome and the agent chooses its own path. In Workflow mode, the builder configures each step, branch, and hand-off. Agents can start manually, on a schedule, or from an event in a connected system. Each step either runs a tool, such as reading data or updating an external system, or applies flow logic. (Glean Docs: How agents work)

Glean also offers Independent Agents. These run under their own identity, with admin-managed credentials, and can work without an active user session. Glean's documentation describes this feature as beta. (Glean Docs: Independent agents)

That range, from a personal helper to a background worker that writes to Jira or Slack, is why one governance policy does not fit every agent.

Why do Glean agents need their own governance in a bank?

Interagency model risk guidance does not settle the question. The revised guidance issued in April 2026, SR 26-2, places generative and agentic AI outside its scope and points banks to their broader risk management and governance practices. FINRA's 2026 oversight report flags agents acting beyond a user's intended scope and outcomes that are hard to trace.

So the bank has to define its own rules. Our agentic AI governance checklist for banks sets out 12 general controls. This article applies them to the specific settings inside Glean.

Whose permissions do Glean agents use?

By default, an agent runs as the person who invokes it. It inherits that user's permissions and tokens and appears as that user in connected apps. (Glean Docs: Agent identity) In the web app, a shared agent uses the signed-in user's own permissions, not the creator's. (Glean Docs: Sharing permissions)

Three cases need a closer look in a bank:

• Slack channel answers. When an agent's Slack response is visible to everyone in a channel, Glean's documentation says it uses a broad-access model and does not check whether every channel member can view each document. Decide which agents may answer publicly, and in which channels.
• API tokens. API requests use the current permissions of the user who created the token. Tie tokens to accountable owners, not departed staff or shared accounts.
• Agent identity. With agent identity, the agent acts as its own principal, using a service credential an admin creates and scopes. Every invoker gets the same fixed permission set. Actions are logged under the agent's account, with the triggering user or schedule recorded separately.

Agent identity is the stronger pattern for anything that writes to systems of record, because logs can separate human action from agent action. It also concentrates risk in one credential, so scope it tightly and review it often.

Which Glean admin settings matter most for agent governance?

Sources: Glean Docs: Agent access, Tools overview, Run without user confirmation, Agent insights.

When should a Glean agent act without a human?

In interactive sessions, users must approve a confirmation card before each write tool runs. Admins can make supported write tools eligible to run without confirmation in scheduled, event-triggered, or background agents. A builder must then enable it for each step and publish. (Glean Docs)

Two details matter for a bank. New custom execute actions default to eligible, and tools from newly configured MCP servers default to allowed. Glean's documentation also warns that the default does not exclude destructive tools such as delete, close, or archive.

Our rule of thumb:

• Inform agents (search, summarize, draft for the user): run as the user, no write tools.
• Recommend agents (draft tickets, messages, or case notes): write tools stay behind confirmation.
• Act agents (update records or post on their own): agent identity, narrowly scoped credentials, destructive tools disabled, and a period in read-only or shadow mode first, as Glean's own Independent Agents guidance recommends.

How should a bank govern MCP tools inside Glean agents?

Glean agents can call tools from remote MCP servers that admins import, and admins can set custom HTTP headers for third-party MCP servers and API gateways. (Glean Docs: Tools) That makes MCP the fastest way to extend agents, and the easiest way to bypass review.

Route every MCP server through the bank's existing approval process. Put it behind an enterprise API or MCP gateway where one exists. Treat each new server as a third-party relationship under the interagency third-party risk guidance, and reset the confirmation setting for its tools before any agent uses them.

What evidence should a bank keep for Glean agents?

Examiners and internal audit will ask what an agent saw, what it did, and who approved it. Plan to keep:

• An agent register with owner, purpose, risk tier, and sharing scope
• The tool and credential list for each agent, with the confirmation setting per step
• Test results against a golden dataset before publishing and after material changes
• Agent Insights exports on runs, failures, and user feedback, reviewed on a fixed schedule
• A record of pauses, unpublishes, and credential revocations

In a 250-user Glean pilot at a bank, the controls that mattered first were permission fidelity and source curation. Agents only behave as well as the enterprise context layer underneath them.

Where does HRTG fit?

HRTG is a member of the Glean Partner Network and works with banks, insurers, and public sector teams. Our Glean Readiness Assessment reviews your agent settings, tool access, and identity model against the questions above. Foundation sets the permissions and connectors agents depend on. Activate launches the first governed agents. Operationalize builds the agent register, review cadence, and evidence. Optimize expands agents safely as adoption grows.

If you are deciding how far to let Glean agents act in your bank, use the form below to talk with our team.

FAQ

What are Glean agents? Glean agents are AI workflows on the Glean platform that use enterprise knowledge and tools to complete tasks. They can run on demand, on a schedule, or from events in connected systems, and can read data, draft content, or update external systems.

Do Glean agents respect user permissions? By default, yes. An agent runs with the invoking user's permissions. Exceptions include Slack answers visible to a whole channel, API tokens that use the token creator's permissions, and agents configured with their own agent identity.

Can Glean agents take actions without human approval? Only if admins and builders allow it. Write tools require confirmation in interactive sessions by default. Admins can make tools eligible to run without confirmation, and builders must then enable it per step.

Should banks use agent identity for Glean agents? For agents that write to systems of record, usually yes. Agent identity separates agent actions from human actions in logs. The service credential should be scoped to exact resources and reviewed regularly.

Where should a bank start with governing Glean agents? Start by reviewing who can create and share agents, disable destructive tools, and keep write actions behind confirmation. Then build an agent register and test agents before they are shared widely.