Skip to main content

​
Direct answer

Grantex supplies verifiable, delegated tool authority for AgenticOrg’s governed business cases. The AgenticOrg source runtime requires one active tenant role agent, a registered provider read-tool manifest, an exact local case-purpose allowlist, and a valid delegated grant before every provider call. A missing or denied check stops the provider call. Case decisions and analyst review remain human actions in AgenticOrg; an agent grant does not approve a case. This describes repository source, not an assertion that a particular hosted tenant has the feature enabled or that the latest main commit is deployed. Check the deployed revision and the tenant’s governed_cases.enabled flag.

​
Responsibility boundary

At the last verified AgenticOrg integration check on September 24, 2026, its Python dependency was grantex==0.5.1. That integration did not enforce token-level purpose or per-case caps for this flow, and a pooled run token was not bound to one case. Python 0.6.1 is now published with general purpose and cap APIs, but a package release alone does not wire AgenticOrg’s case context into enforcement. Recheck AgenticOrg’s deployed dependency and flow before claiming this as a production control. See Release Status.

​
Operator setup

  1. Review the selected provider’s manifest and allow only the read tools the business-underwriter and screening-disposition roles need.
  2. Register exactly one active, shared tenant agent for each role in AgenticOrg. Verify each stored Grantex agent ID and derived scope set.
  3. Set each role’s exact case_purposes list and provision a root grant that covers the registered tools. Keep credentials in a secret manager.
  4. Configure a reviewed case policy and provider. The bundled mock provider is for local and test environments, not production verification.
  5. Run denied-path tests for missing role, wrong purpose, missing grant, revoked grant, undeclared tool and provider failure before enabling the tenant flag.
  6. Confirm the deployed SHA and operator logs before describing the flow as available to users.
AgenticOrg’s case lifecycle and grant-enforcement runbook are the implementation and operations sources of truth.

​
SDK and MCP boundary

Machine-safe submit, list, read and investigation-scheduling methods for the AgenticOrg Python and TypeScript SDKs are proposed in AgenticOrg PR #1401. At this guide’s September 24, 2026 check, they are not in AgenticOrg main or its published 0.3.0 client packages. Evaluate them from that PR’s source branch until it is merged, released and verified separately. Scheduling an investigation is not proof it succeeded; inspect the later case state. AgenticOrg’s MCP server advertises general agents-as-tools, not the governed case roles. Grantex MCP transport authorization and tool authorization are separate from AgenticOrg’s human case-decision path. Neither MCP discovery nor an agent token can stand in for a signed-in person or a verified decision grant.

​
Decision grants and the agent binding

The Grantex auth service setting DECISION_GRANT_AGENT_BINDING (off by default) binds decision grants to the agent a request names and stops GET /v1/decisions/requests/{id} returning them to the developer API key (see Decision Grants). An integration that records a decision by reading decisionGrants from that GET and presenting them to POST /v1/decisions/consume stops working when the binding is on, because the list is no longer returned. Before the binding is turned on, such an integration:
  1. Consumes its own decisions by request id. A request created without agentId or grantId is consumed with POST /v1/decisions/requests/{id}/consume and {"action": ..., "caseVersion": ...}, so its grants never leave Grantex. The answer has the same shape as POST /v1/decisions/consume (requestId, jtis, actionHash, and approvers each with sub and jti).
  2. Consumes at the same point as before. If the decision is recorded under a lock today, the consumption by request id happens under that lock too. “Not approved yet” comes from the request’s own state, or from an unknown_grant or four_eyes_incomplete refusal, rather than from an empty grant list.
  3. Reads subReason before the HTTP status. Grantex refuses a grant presented for another agent with 403, "reason": "decision_invalid" and "subReason": "wrong_agent", which is not an authentication failure.
  4. Leaves agent decisions to the agent. Grants of a request made for an agent (agentId, grantId) are released only to that agent’s grant token (POST /v1/decisions/requests/{id}/grants) and consumed only when the same agent’s grant token accompanies the consumption (grantToken on POST /v1/decisions/consume). Grantex establishes the agent from that token, never from agent or grant identifiers in the request body, so the developer API key alone cannot consume them. The SDKs’ enforce() sends the token it verified, as Decision Grants describes.
Consumption by request id and the grants endpoint work with the binding off, so an integration can move to them and be verified first. Turn the binding on only after that, and confirm that a four-eyes decline is recorded end to end.

​
Future integration gate

Token-level purpose, decision and cap features should be enabled only after a published SDK is installed, its API is pinned, AgenticOrg passes the case context to enforcement, and cross-tenant, replay, expiry, revocation, and per-case budget tests pass. Do not infer those guarantees from a dependency version bump alone.
Last modified on September 28, 2026