Configured tool requests can be checked against declared scopes. Audit coverage depends on the enabled integration and retention settings.
Without proper enforcement, AI agents can do things you never intended.
Without a correctly configured enforcement boundary, a READ-scoped agent could still reach a destructive tool.
A runtime that does not re-check expiry or revocation can continue with stale authorization.
"process_refund" sounds harmless, so it's treated as a READ. But it actually moves money.
Five control stages in this illustrative authorization flow.
When you create an agent, Grantex creates a grant token — like a keycard that only opens specific doors.
"This agent can READ Salesforce contacts but NOTHING else."
The AI agent reasons about its task and decides it needs to call a tool — perhaps delete_contact.
Before the tool runs, Grantex looks up delete_contact in its manifest and sees it requires DELETE permission. The agent only has READ.
DENIED.
In this simplified hierarchy, a WRITE grant includes READ, while a READ-only grant does not authorize WRITE, DELETE, or ADMIN operations.
When audit integration is enabled, allow and deny events can record timestamp, agent, tool, connector, and reason. Completeness, retention, immutability, and audit suitability must be verified for the deployment.
A clear comparison of what changes with Grantex.
Permission guessed from tool name keywords
"process_refund" classified as a harmless READ
No enforcement layer in LangGraph pipeline
Agents call tools directly with no middleware
Keyword matching is brittle and incomplete
"generate_invoice" might mean READ or WRITE
No audit trail of permission decisions
Missing authorization evidence makes later review incomplete
Manifest-based: each tool declares its required permission
No guessing. delete_contact = DELETE. Period.
Offline JWT verification at the LangGraph boundary
No network call needed. Tokens are self-contained.
Local token checks can avoid a provider round trip
Measure latency and failure behavior in your deployment.
Manifests describe supported native connector tools
Verify manifest coverage against the current runtime registry.
A fictional authorization example, not a live tenant trace or production-readiness result.
User creates Sales Agent
Token scopes: tool:salesforce:read:*
Agent thinks: "I need to get contacts"
Calls get_contact
Grantex checks: get_contact needs READ
ALLOWEDAgent has READ --> ALLOWED
Agent thinks: "Let me delete this old contact"
Calls delete_contact
Grantex checks: delete_contact needs DELETE
DENIEDAgent has READ --> DENIED
Agent responds to user
"I don't have permission to delete contacts."
In repository source, the governed-case runtime checks an active tenant role, its registered provider tools, the exact case purpose on a local allowlist, and a delegated grant before every provider call. A missing or denied check stops the call. The case feature is off until an operator enables and configures it for a tenant; availability in a hosted deployment depends on its deployed revision.
An agent can prepare evidence and a recommendation. A signed-in person must review or decide the case; an API key, agent token, or MCP tool cannot act as that person. The currently published Grantex Python SDK checks token and tool authority, but does not yet enforce a token-level case purpose or a per-case cap. The local purpose check is not a substitute for those future controls.
Read the case setup and enforcement boundaryTest manifest coverage, token handling, denied cases, audit records, latency, and rollback in your own deployment before relying on these controls.