GrantTap governance: a decision that reaches the tool

Availability, policy, and usage are different facts

A capability can be installed without being allowed for a particular Project. It can be allowed without having been used. It can be selected in a handoff or a plan without being executed. GrantTap keeps those states separate because combining them creates misleading controls and misleading telemetry. An available MCP server is a candidate for work, not evidence that it handled a command. A listed skill is information about the environment, not a completed step. A provider's native enforcement support also has to be described independently of the user's desired policy.

This separation makes the interface more useful. The user can inspect what is present, what is permitted, and what usage was actually observed without inferring one from another. For an agent, the consequence is equally practical: finding a tool in the environment does not remove the need to evaluate its proposed action. For reporting, unknown usage remains unknown. GrantTap does not ask a model to fill an unavailable resource metric with an estimate presented as measurement. Deterministic observation supplies the facts it can establish, while the product retains the source and uncertainty of information that comes from reports or incomplete provider support.

A global prohibition remains a prohibition

Policy evaluation considers provider, account, Project, and Task effects while preserving the rule that a global capability deny wins. A Task's local permission cannot override a prohibition at the account boundary simply by choosing a different model or setting an automatic acceptance mode. This is important when the same Project spans computers and providers. The user should be able to express a durable restriction without depending on every chat to remember its wording. The computer evaluates the proposed action against that restriction at the point where the tool would be admitted.

Our real Engine scenario supplied an account deny together with Project and Task allow effects and verified that the resulting decision was deny. A separate persisted Project rule prohibited file writes. Native Claude and Codex hook calls then evaluated the applicable Project and refused a write even though the isolated runtime had automatic acceptance enabled. The fixture did not edit the user's repository or provider configuration. It exercised the actual hook entry points and local Engine using a dedicated temporary runtime. This is stronger evidence than checking that a prompt contains a warning, because it verifies the path that decides whether the tool proceeds.

Tie a decision to the correct action

A useful authorization refers to a particular proposed invocation. Its provider, session, capability fingerprint, and available scope help identify what the user is being asked to approve. GrantTap's Codex path separates early policy handling from the later permission request. An ASK can be bound to the exact native call and consumed once, preventing one approval marker from applying to a different command. Provider details differ, so the adapters implement their own native contracts rather than assume that an identical text response will enforce permission everywhere.

Exactness also matters when a capability changes. A server name can remain the same while its executable, configuration, or transport changes. A fingerprint can carry the evidence available for that identity, with confidence reported explicitly. Name only or unknown confidence should not be described as an exact match. Cursor's implemented MCP path prepares a redacted fingerprint rather than shipping raw tool arguments or credential bearing configuration to policy evaluation. The resulting decision is about an identified capability with stated evidence. It does not turn a recognizable label into proof that every future invocation of that label has the same behavior.

ASK means an actual decision point

An ASK rule is useful only if the supported provider path can stop and obtain the needed decision. GrantTap distinguishes that requirement from an ordinary informational message. In the tested Claude path, Project ASK precedes bypass and automatic acceptance. If the required approval is not obtained within the configured test deadline, the tool is refused. The Codex path binds an ASK to its exact call so that the permission hook handles it at the proper native stage. The user sees a decision about work that is waiting, rather than a report describing work that already happened.

This approach also helps avoid repeated reasoning. A stable policy can decide routine allowed or denied actions algorithmically. The model need not spend another conversation restating the same permission boundary, and the user need not answer a broad question that was already resolved by a rule. Actions requiring judgment remain explicit. The purpose is not to eliminate every approval; it is to put each approval at the correct boundary with a specific scope. A smaller number of appropriate decisions is more useful than a stream of generic requests, especially when several agents are progressing on different parts of a Project at the same time.

Coverage makes enforcement inspectable

Policy intent and enforcement coverage remain separate. GrantTap can record which endpoint and provider acknowledged a policy revision and which capability classes are enforced, observed, unsupported, or unknown. Strict readiness depends on those acknowledgements. A green policy description alone cannot prove that a particular native integration can intercept the relevant action. This is especially important for a Project that spans computers, where one endpoint might have a ready hook and another might be missing the provider integration required to apply the same rule.

Coverage gives the user a specific next check. Verify the endpoint, provider, policy revision, and capability class associated with the proposed work. Acknowledging file write enforcement does not prove deployment enforcement, and observing a command does not prove it was blocked before execution. GrantTap's tests exercise policy revision handling and the supported native hook contracts. The real daemon check additionally verifies that a stored rule survives restart and is still evaluated. Together, those checks support honest descriptions of implemented behavior while keeping unsupported coverage from becoming a silent promise that every possible tool path is controlled identically.

Keep project decisions durable and scoped

A rule should survive a daemon restart without relying on a model to repeat it. Engine persists Project policy and related state, and mutation handling preserves transactional behavior when a state write fails. The research scenario wrote a Project deny rule, stopped Engine, started it against the same isolated state, and verified that the deny still applied. Durable storage is useful for continuity between executions, but scope remains essential: resolving the correct local Project binding determines which Project policy is applicable to a proposed action on that computer.

That binding includes endpoint and repository context. An account can contain many computers, and a directory path on one machine does not automatically identify the same checkout on another. Mesh helps preserve Task and repository relationships, while policy evaluation resolves the local action's Project. A handoff therefore requires both coordination readiness and destination policy readiness. Moving work to another model does not reset its constraints. The recipient should inherit the relevant Task facts and evaluate the actions it proposes through its own supported local enforcement path, with acknowledgements and revisions that describe its actual state.

Evidence can guide work without granting authority

Cortex packets and Mesh memory may contain exact source, graph relationships, user decisions, or agent reports. Those items guide investigation and architectural work. They remain data within their stated provenance. A source comment asking an assistant to ignore its rules is still source content; a peer report suggesting a command is still a report. Governance is evaluated through the action path rather than by treating whatever text the model reads as a new permission. This allows GrantTap to share useful project knowledge while keeping a clear boundary between context and authorization.

The same reasoning applies to refactor previews and local model advice. A preview identifies a proposed transformation and its consequences; it does not authorize applying the transformation. A classifier can recommend a route or a draft; it does not change the capability deny rules of the computer. Tests, source inspection, and policy checks serve different roles. Keeping their results separate reduces the chance that an economical context pipeline will accidentally amplify an unsupported instruction. It also helps reviews: the person can see what evidence justified a change, which rule admitted the action, and which behavioral verification established the resulting outcome.

Governance can reduce avoidable work

A prohibited action that is stopped early does not require the agent to explain and undo an accidental change later. An exact ASK avoids a second clarification about which command was approved. A persisted rule removes the need to reconstruct the user's boundary after every provider change. These are plausible and concrete sources of reduced work, although our experiment did not assign a universal token percentage to them. The measured outcomes were decision precedence, refusal through native hooks, and persistence. Their value comes from making the next step reliable and bounded, so the model can concentrate on permitted engineering work.

The practical workflow is to connect the appropriate computer, inspect the Project and Task, understand current capability coverage, and continue through the supported native path. GrantTap supplies compact context and observed state algorithmically. When an action requires a decision, it presents that decision with the available identity and scope. When a restriction already answers the question, it enforces the result on the computer. This complements Cortex's context economy and Mesh's reusable work history: fewer repeated explanations, fewer ambiguous transitions, and a clearer connection between the user's intention, the admitted invocation, and the verified result of the coding work. ## From a card to a confirmed chat rule

Tap the body of an approval card to inspect its command, folder and bounded parameters. Allow and Deny remain separate actions. The automation section lets you draft a rule for this chat and apply it explicitly. “Waiting for the computer” means that the rule is still pending; it is shown as applied only after the same authenticated computer confirms the operation and effective level. A timeout restores the last confirmed state. Changing one chat does not resume global automation, and a Project deny still wins.

Claude question menus use a different form: each original question keeps its choices, multiple selection and a custom answer. Every question must have an answer before submission. A permission Allow without answers cannot complete this form, and Auto allow never chooses an answer for you. Answers join the durable decision outbox when offline; the form waits for the native computer to confirm them after reconnecting.