Governance · · 7 min read
Agent governance must reach the computer
An allow/ask/deny switch is only the beginning. Effective policy, host enforcement, and observed use need separate evidence.
When an agent can call a shell command, an MCP tool, or a skill, a policy screen is only useful if a real execution boundary honors it. A saved preference is not the same as a rule applied on a computer, and an approved capability is not evidence that it was invoked.
This is why GrantTap separates desired policy, effective policy, host state, and confirmed use. A global deny wins over a Project allow. Unknown coverage stays unknown until the target computer can report what it enforced.
From decision to action
A capability has an exact identity: the MCP server configuration or skill bundle matters, not only the name shown to a person. A request and an approval belong to that identity. Each target host must report what it actually applied and initialized. Complete cross-host bundle transfer is still unfinished, so approval alone cannot promise readiness on another computer.
Auto-accept belongs after the effective policy check. A broad provider setting is not a substitute for computer enforcement. Even with a correct policy engine, an action outside its observed path cannot be described as protected by it.
Usage is a separate fact
A selected tool, an accepted proposal, and a configured server are three different states. Confirmed usage requires evidence from a real invocation. The same distinction applies to spending: reporting token use is useful, but it is not a hard budget. A strict cap requires reservation before a controlled billable action and careful handling of in-flight or unknown results.
AWS describes a related principle in Amazon Bedrock AgentCore: gateway policy can evaluate routed tool calls before execution, and temporal policies can consider a sequence of actions. That does not automatically govern a local coding agent's shell or every provider-native route. The enforcement boundary must match the actual path of the call.
What the person should see
A useful governance view names who requested a change, its scope, the exact capability, the effective rule, the target computer, and the computer's reported outcome. A refusal should explain which rule stopped the action. A stale acknowledgement should not overwrite a newer decision.
GrantTap's current product pages describe the available controls and their limits. There is no strict spending cap or use-only credential broker in the current release. The interface must continue to distinguish unfinished paths from controls already enforced.
A decision must have a destination
A governance setting is useful only if its scope is clear. Which Project, Task, capability identity, member, computer, and provider execution does it concern? A broad label such as ‘tools allowed’ hides too much. The target host performs the local action, so a decision made on a phone needs a route to that host and a way to learn whether it was applied. A policy selected in a UI is an intention until the enforcement path confirms it.
This is especially important when a Task can move. A policy approved for one MCP configuration on a laptop does not necessarily authorize a different configuration on a desktop. The same display name can cover different commands or bundled files. New identity or new host state calls for a fresh readiness check. The owner should see the gap before pressing a continue button, rather than discover after the agent has depended on an unavailable tool.
The host is the enforcement boundary
The computer that runs a command must enforce the decisions it owns. A phone can help a person choose, but cannot by itself stop a shell command on an unobserved provider-native path. A global deny should win where the host control applies, and auto-accept should happen only after the effective rule is checked. If a route bypasses that control, the product must describe the coverage limit rather than report a universal block.
A host receipt can report which rule and capability configuration it applied. It is more informative than a generic success toast, but still narrower than a verified outcome. A receipt cannot guarantee that a future process restart keeps the same state. It also cannot prove that no action occurred outside its observation boundary. Good governance shows where computer-enforced decisions are real and where the evidence ends.
Separate four questions
First, what rule did a person choose? Second, did the target host accept and apply that rule? Third, did the agent actually invoke the capability? Fourth, what result can be verified? These questions form a chain, not a single status. A denied request may never reach a tool; an allowed request may never be used; a successful invocation may still produce a failing test. Each stage needs its own timestamp, source, and uncertainty.
The second illustration presents those checkpoints as separate objects. It is not live telemetry. In the real product, an unknown stage should remain unknown. For example, if the provider integration cannot observe a native tool call, the absence of a usage event is not evidence of zero use. If a host was offline, a selected rule may be pending rather than applied. This discipline prevents a reassuring dashboard from overstating protection.
Credentials and budgets need stronger controls
A permission to use a tool is different from permission to read its raw credential. Putting a secret in a masked setting does not shield it from a process that receives that environment value. A use-only design would require a trusted broker performing a narrow operation without handing the secret to a general-purpose agent shell. That is a separate implementation and threat model, not a benefit that follows automatically from an approval screen.
The same caution applies to money. An observed token count is useful for understanding past work, but it does not reserve funds before the next model call. A strict budget requires control at the point of expenditure, including concurrent work and uncertain outcomes. Until a route has that mechanism, the product should say it reports usage where confirmed rather than promising a spending cap. Distinguishing current evidence from future control is part of governance itself.
A practical policy review
For a new capability, inspect the exact configuration or bundle digest, choose the Task and host that need it, and ask what actions it can perform. Decide whether allow, ask, or deny fits that scope. Then inspect the target host's observed configuration and initialization result. Try a harmless call if the path supports it, and review the invocation evidence. If any stage is missing, stop at that stage instead of treating the next one as implied.
For shared work, also check the member's Project grant. Linking repositories does not expand a member's access by itself. The owner's phone may guard protected Project forwarding, while a local host still enforces the action it runs. A named Project is the coordination scope, not a universal authority token. This matters when one contributor can review a Task but should not execute a release command on someone else's computer.
A useful governance screen
The screen should lead from a decision to its evidence. Show the rule, its exact scope, the computer that reported applying it, observed use, and the result that can actually be verified. Let a person inspect why a capability is unavailable without guessing. Unknown values are not errors to paint over; they identify the next diagnostic step. A product is safer when its interface makes it hard to confuse intention, enforcement, and outcome.
GrantTap's current cross-host bundle transfer and some durable apply receipts remain incomplete, as described in the capability guide and runtime documentation. The generated images above explain the intended chain, and the product screenshot below uses deterministic demonstration data. They should not be read as evidence that every provider route is already covered. The practical standard is modest but demanding: can a person tell which computer applied which rule to which action, and what remains unobserved?
