Permissions for AI workers

Give AI agents exactly the access they need.

Grantry is the permission layer between your AI agents and your business tools. One scoped token per worker, human approval before ad spend, code pushes, or CRM edits — and an audit log of every call. Built for ops teams and agencies running AI workers in production.

Works with Claude Code, Codex, and any MCP-compatible agent.

Governs agent access to

Raw tokens on laptopsCentral credential custody

Every tool exposedPolicy-filtered MCP

No account boundaryConnection-level access

No proof after actionComplete audit trail

The pain

Agents are becoming operators before teams have operator controls.

Token sprawlCredentials leak into runtimes

Every local MCP config becomes another place to rotate, revoke, and debug access.

OverexposureAgents see too much

If a worker can discover a tool, it can often try to use it, even when the job does not need it.

Risky actionsRead and write look the same

Campaign edits, CRM updates, code pushes, and emails need stronger gates than analytics reads.

Account confusionThe wrong client is one call away

Agencies and operators need the right account, property, repo, or workspace selected by policy.

No recordAfter the action, nobody knows

Teams need to know which worker called which tool, through which credential, and what happened.

The solution

Put a governed lane between AI workers and business systems.

01

One worker token

Give Codex, Claude Code, or a scheduled agent one scoped Grantry token instead of a bag of SaaS secrets.

02

Only allowed tools appear

Filter tools before the agent sees them, so a sales worker never discovers production GitHub actions.

03

Credentials stay server-side

Keep OAuth grants, PATs, refresh tokens, private app tokens, and developer tokens outside prompts and laptops.

04

Right account, every time

Route calls to the correct repo, MCC, property, workspace, portal, or customer connection by role and scope.

05

Dry-run before mutation

Let agents analyze and validate freely, then require approval before spend, publish, push, or customer-facing changes.

06

Audit every attempt

Record the worker, role, tool, connection, request, response, and result, including blocked calls.

How it works

Job roles become executable permission policies.

A role is not just "Google Ads access" or "GitHub access". It decides which worker can call which action, through which credential, inside which customer or workspace.

AI worker Service Allowed action
Ads Operator Google Ads Search campaigns
Ads Operator Google Ads Mutate after approval
SEO Analyst GitHub Create issue
Sales Ops HubSpot Update deal
Any worker Production push Denied

Use cases

Start where an agent mistake is expensive.

Paid media

Let agents analyze campaigns and experiments, then require approval before budget, bid, keyword, or creative changes.

SEO operations

Read GSC and GA4, update Notion, open GitHub issues, and keep deploy or DNS actions outside the role.

Sales operations

Let agents update CRM records through the right portal while email, Drive, and enrichment tools stay separately governed.

Positioning

Grantry sits between AI agents and the tools they operate.

Connector catalogs help agents reach more tools. Gateways move MCP traffic. Grantry answers the business question: should this worker be allowed to do this action, in this account, right now?

ModelsOpenAI, Anthropic, Google
Agent frameworksLangGraph, Agents SDK, CrewAI
Connector platformsComposio, Arcade, Pipedream, Zapier
MCP gatewaysContextForge, Agentgateway
AI worker permissionsGrantry

FAQ

Common questions before teams switch on agents.

Where do credentials actually live?

OAuth grants, PATs, refresh tokens, and developer tokens are stored encrypted on the Grantry server. Agents receive one scoped Grantry token — raw SaaS credentials never appear in prompts, local MCP configs, or agent runtimes.

Which services are supported today?

GitHub, Notion, Google (Drive, Search Console, Ads), and HubSpot, with more connectors on the way. Anything reachable over MCP can sit behind the same policy layer.

How do approval gates work?

Read and analysis tools run freely. Actions you mark as risky — spend changes, publishes, pushes, customer-facing edits — pause until a human approves. Every attempt, approved or blocked, lands in the audit log.

Does my agent need code changes?

No. Grantry is a standard MCP server. Point Claude Code, Codex, or any MCP client at the Grantry endpoint with its worker token, and the agent only sees the tools its role allows.

What shows up in the audit trail?

The worker, role, tool, connection, request, response, and result for every call — including calls that were blocked or are waiting on approval.

Grantry

Give AI workers the access they need, and nothing more.

Start for free

Questions before you start? Email [email protected].