You Own the Manifest
Grantex is a permission enforcement engine, not a connector catalog. The 53 pre-built manifests are a convenience — the real power is that you define permissions for any tool your agent calls.Any Connector
Internal APIs, new SaaS tools, proprietary services — if your agent calls it, you can enforce it.
Zero Dependency
No waiting for a Grantex release. Define a manifest in your codebase, enforce immediately.
Identical at Runtime
Custom and pre-built manifests use the same enforce() engine, permission hierarchy, and JWT scope resolution.
Multiple Sources
Define inline, load from JSON files, load a directory, auto-generate from source code, or extend pre-built manifests.
Define Inline
The most common approach — define a manifest right in your code:Load from JSON Files
Store manifests as JSON for version control, code review, and team sharing:inventory-service.json
Load a Directory
If you keep manifests as.json files in a folder, load them all at once:
Auto-Generate from Source Code
The CLI can scan your tool definitions and generate a manifest automatically:get_* → read, create_* → write, delete_* → delete). Always review the output — the inference is a starting point, not a guarantee.
Extend Pre-Built Manifests
Add tools to any existing manifest — pre-built or custom:Mix Custom and Pre-Built
Most production deployments use both. Load pre-built manifests for well-known connectors, custom manifests for everything else:Permission Hierarchy
All manifests — custom or pre-built — use the same four permission levels:| Granted Scope | READ Tools | WRITE Tools | DELETE Tools | ADMIN Tools |
|---|---|---|---|---|
tool:X:read | Allowed | Denied | Denied | Denied |
tool:X:write | Allowed | Allowed | Denied | Denied |
tool:X:delete | Allowed | Allowed | Allowed | Denied |
tool:X:admin | Allowed | Allowed | Allowed | Allowed |
tool:{connector}:{permission}:{resource}. Your custom connector name goes in place of {connector}:
Validation
Validate your manifests before deploying:The CLI commands
grantex manifest validate and grantex enforce test currently only work with the 53 bundled manifests. For custom manifests, use grantex manifest load to inspect the file, and test enforcement programmatically using the SDK’s enforce() method directly.FAQ
Do I need Grantex to add support for a new connector?
Do I need Grantex to add support for a new connector?
No. Define a
ToolManifest in your codebase and load it at startup. The enforce engine makes no distinction between your manifests and the bundled ones.What about connectors I don't control?
What about connectors I don't control?
Use the pre-built manifests for well-known connectors (Salesforce, Stripe, etc.). For third-party connectors not in the bundled set, define your own manifest based on the connector’s API documentation.
Can I override a pre-built manifest?
Can I override a pre-built manifest?
Yes. Load your own manifest with the same connector name — it fully replaces the previous one (all tools, not just overlapping ones). If you want to keep the original tools and add new ones, use
add_tool() instead.What happens if a tool isn't in any manifest?
What happens if a tool isn't in any manifest?
enforce() returns allowed: false with the reason “Unknown tool”. This fail-closed default means agents cannot call tools that were never declared.How do I scope tokens for custom connectors?
How do I scope tokens for custom connectors?
Use the same format:
tool:{your-connector}:{permission}:*. For example, tool:inventory-service:write:* grants write access to your inventory service.Related
- Tool Manifests concept — permission hierarchy, scope format, fail-closed behavior
- Scope Enforcement guide — end-to-end walkthrough with framework integrations
- CLI manifest commands — browse, validate, and generate manifests
- AgenticOrg case study — 53 pre-built + custom manifests in production