How Glean ensures skills stay secure and permissions aware

Imagine an employee imports a useful-looking skill from a public repository – a “quarterly report formatter” with clean instructions and a helpful example script. But a reference file contains another instruction: pull data from the CRM and send it to an outside server.

An agent could execute on both tasks, even though the employee asked only for a formatted report.

Skills, by definition, package tools and expertise as code, and can be shared across systems. When enterprise platforms and their coding harnesses implement them naively, skills can hide overpermissioned access and invite malicious code injection. A poorly scoped or over-privileged skill can nudge an agent toward data it shouldn’t touch, tool chains that aren’t safe to chain, or actions that drift from what the user actually intended.

That’s the core design problem: how do you let enterprise extend AI behavior without turning every new skill into a new avenue for data leakage, unsafe execution, or uncontrolled sprawl?

In this blog, we explain the security problem skills pose and how we designed Glean to make them safe to use in the enterprise. We walk through how Glean secures skills at each stage of their lifecycle:

1. Scanning before entry
2. A credential broker at runtime
3. Access controls to scale safely 

Scanning skills before it runs

Skills may come from private repos, public marketplaces, open formats, GitHub-based workflows, or external tools – none of that should grant a shortcut around governance. The same review, scanning, and publishing controls must be applied no matter where a skill originated.

Glean’s scanning model evaluates skills at creation, upload, import, sharing, and publish time – and automatically rescans them whenever they change. Critically, it treats the entire skill package as an attack surface, scrutinizing the visible description, metadata, examples, scripts, references, and attachments for:

• Prompt injection or hidden instructions
• Data exfiltration risk or suspicious outbound destinations
• Dangerous tool usage / excessive agency, like nudging the assistant toward broader tools than needed

Each skill gets a verdict – pass, review recommended, or blocked – with explanations on the risk factors behind it. Admins and Skills Moderators can review the findings, request changes, mark a skill safe, or block its current version.

Isolating skills at runtime

A skill can shape an agent’s behavior, but it should not control the environment it runs in or hold the credentials it uses. Glean ensures this by running skill files and code inside an isolated sandbox. When a skill needs an external system, a credential broker checks the destination and request against policy, then mediates access with only the permitted credential. The credentials stay outside the skill and sandbox, and policies can block requests to unapproved destinations.

This is one application of Glean’s broader secure agentic-execution architecture and not a skills-only control. Sandboxes contain untrusted agent code; credential brokers govern where it can connect, under whose identity, and with what authority.

Skills shape behavior, while sandboxes constrain execution and brokers govern access. This separation secures skills without treating them as trusted code.

Governance is what makes skills safe to scale

Runtime controls are only half the story. The other half is governance.

Glean’s view here is simple: administrators set the ceiling, users set the floor. Power users can create or import skills freely – bottom-up creation is where the best skills come from. Teams adopt the useful ones. Admins decide what gets promoted to department or organization scope, which gets auto-enabled, and what gets pulled back.

In practice, governance of skills shows up as:

• Access controls on user- and org-level sharing
• Administrator and moderator roles
• Draft-to-publish lifecycle management with versioned history and rollback
• Priority to personal skills when there is naming overlap with admin-published skills
• A trusted catalog of skills over a broad, unvetted one

Openness and control are not a trade-off

There’s a false choice floating around the market: either you participate in the open skills ecosystem, or you maintain enterprise control. Enterprises should be able to do both.

Glean supports GitHub-based imports (both public repositories and private repositories the user is authorized to access) and skills invoked through MCP, so enterprises can adopt skills from the broader ecosystem without compromising centralized governance. Every one of those skills passes through the same scanning, sandboxing, brokering, and governance described above.

This distinction only grows more important over time. As skills spread across more surfaces, durable value won’t come from being the only place skills can be authored. It will come from being the place where they’re safely governed, evaluated, distributed, and improved.

The enterprise promise: reusable expertise with policy built in

Skills are becoming an important part of enterprise AI – an open standard for packaging and reusing expertise. But like any mechanism that gives model reasoning the ability to freely change a live environment, they need to be governed, which makes them one of the more important new security boundaries too.

The right architecture is governed by isolated execution, broker-mediated access, policy enforcement outside runtime, scanning before distribution, and admin controls that let companies decide what skills are ready to scale across the organization. Glean delivers all these capabilities on its platform, enabling skills to be brought into everyday work without putting them outside the company’s security and governance controls.

Feature availability: These capabilities are now generally available, including secure skills execution, skills governance, skill scanning, skills imported via GitHub, and skills imported via Glean MCP.