> ## Documentation Index
> Fetch the complete documentation index at: https://docs.grantex.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Grantex and AgenticOrg Governed Cases

> What Grantex verifies for AgenticOrg business onboarding cases, what AgenticOrg enforces locally, and which purpose and cap controls are not yet wired into the integration.

## 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

| Control | Current owner | What to verify |
| - | - | - |
| Tenant, case state and human actor | AgenticOrg | Tenant isolation, enabled flag, state transition and a signed-in person for decisions or reviews |
| Case-purpose allowlist | AgenticOrg | Exact `case_purposes` on the selected active role; this is local configuration, not a token claim |
| Delegated tool authority | Grantex grant, checked by AgenticOrg through the published Python SDK | Token signature, expiry, registered agent identity, connector, tool and permission |
| Provider response and evidence | Provider and AgenticOrg | Provider access, cited response, policy version, case record and hand-off |
| Token-level purpose, case-bound cap | Not active in this integration | Do not represent the local allowlist or a general budget as either control |

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](/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](https://github.com/mishrasanjeev/agentic-org/blob/main/docs/governance/case-lifecycle.md)
and [grant-enforcement runbook](https://github.com/mishrasanjeev/agentic-org/blob/main/docs/operations/grant-enforcement.md)
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](https://github.com/mishrasanjeev/agentic-org/pull/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](/concepts/decision-grants#binding-decisions-to-the-requesting-agent)).
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](/concepts/decision-grants#binding-decisions-to-the-requesting-agent)
   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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.