One worker token
Give Codex, Claude Code, or a scheduled agent one scoped Grantry token instead of a bag of SaaS secrets.
Permissions for AI workers
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
Every local MCP config becomes another place to rotate, revoke, and debug access.
If a worker can discover a tool, it can often try to use it, even when the job does not need it.
Campaign edits, CRM updates, code pushes, and emails need stronger gates than analytics reads.
Agencies and operators need the right account, property, repo, or workspace selected by policy.
Teams need to know which worker called which tool, through which credential, and what happened.
The solution
Give Codex, Claude Code, or a scheduled agent one scoped Grantry token instead of a bag of SaaS secrets.
Filter tools before the agent sees them, so a sales worker never discovers production GitHub actions.
Keep OAuth grants, PATs, refresh tokens, private app tokens, and developer tokens outside prompts and laptops.
Route calls to the correct repo, MCC, property, workspace, portal, or customer connection by role and scope.
Let agents analyze and validate freely, then require approval before spend, publish, push, or customer-facing changes.
Record the worker, role, tool, connection, request, response, and result, including blocked calls.
How it works
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.
Use cases
Let agents analyze campaigns and experiments, then require approval before budget, bid, keyword, or creative changes.
Read GSC and GA4, update Notion, open GitHub issues, and keep deploy or DNS actions outside the role.
Let agents update CRM records through the right portal while email, Drive, and enrichment tools stay separately governed.
Positioning
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?
FAQ
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.
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.
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.
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.
The worker, role, tool, connection, request, response, and result for every call — including calls that were blocked or are waiting on approval.
Grantry
Questions before you start? Email [email protected].