gove-zone
Beta · release candidate
Control a tool call
Require authorization before an integrated action runs.
Start with one tool and an explicit execution boundary.
Open evaluation guide
Meet the execution boundary
Let agents work. Keep control.
Check a proposed tool call before it runs. Keep the decision for review.
Availability and maturity vary by component. Controls apply only to integrated execution paths.
Control at the point of action
Check before execution
Stop on escalation
Inspect the evidence
At the point of action
One proposed action.
One clear decision.
Explore the kernel's four verdicts. ALLOW and TRANSFORM can authorize a verified call. DENY and ESCALATE stop execution.
Follow the execution pathOne action. A clear boundary.Interactive example
Agent requests an action
Read a project document
- Agent
- research-assistant
- Tool
- documents.read
- Scope
- Project Atlas / approved files
gove-zone boundary
Check the action before the tool runs
Illustrative decision
AllowedRead access is permitted within this project.
policy / project-readMay proceed
Illustrative policy outcomes. No signed receipts are generated and no tools are executed.
The execution path
A good answer is not permission to act.
An agent can propose a useful action and still exceed its authority. gove-zone brings your policy into the integrated execution path, where the decision matters.
Explicit integration
Only tool paths routed through the governed executor are covered. The runtime is not a sandbox for every action an agent could take.
Configuration matters
Signing, replay protection, identity, and audit storage depend on the package and deployment configuration. Verify the controls you intend to rely on.
- 01
Define the scope
Set which actions, resources, and conditions are allowed for a governed tool.
Your policy
Read approved project files
- 02
Check the request
Evaluate the proposed action and issue its decision receipt. A transformed call uses only the approved arguments.
The decision
Allow, transform, deny, or escalate
- 03
Verify, then execute
Check the receipt against the exact call before running the tool. Retain the decision and audit record for review.
Your record
Exact call and verified decision
Find a starting point
What should your agent be allowed to do?
Choose the action you want to control. Begin with one local evaluation and expand only after you understand its scope.
ACGS-Lite
Beta
Check a Python action
Evaluate a request against your configured policy.
Start with a local policy check, then inspect governed wrappers.
A policy check alone does not gate a tool call. Inspect the executor integration and bounded contexts separately.
Open evaluation guide
CFT Governance Pack
Early source companion
Review a cloud plan
Check a Google Cloud Terraform plan before apply.
Start with plan JSON; your pipeline enforces the result.
Open evaluation guide
Put one real workflow under your control.
Choose one tool. Define what it may do. Inspect what happens when a request crosses the boundary.
Governed workflows
Where autonomy meets responsibility.
Start with one consequential action. Make its permissions and review requirements explicit before expanding the workflow.
Source-backed evaluation examples. Customer deployments and business results are not claimed.
Document & client workflows
Draft freely. Release deliberately.
Explore matter-scoped document access and review before client communication or submission. The local example uses mock tools.
Explore the legal workflowCloud infrastructure
Check the plan. Before the change.
Evaluate Google Cloud Terraform plans for configured IAM, network, and resource rules. Your CI pipeline enforces the result before apply.
Explore plan checksAgent tool execution
Authorize this call. Within this scope.
Bind a decision to the actor, tool, and exact arguments. At the integrated executor, deny or escalate outcomes stop the call.
Explore the execution boundaryThe governance library
Read the boundary.
Question the evidence.
Explore operating patterns, recognize failure modes, and inspect what each artifact establishes.
Explore developer resourcesEvaluate before production
Review release status, operational requirements, and current evidence. A receipt alone does not prove that an external action succeeded. A package or policy outcome does not establish regulatory compliance.
Operating patterns
Governance patterns
Choose operating modes and controls appropriate to an agent task.
Risk catalogue
Failure modes
A practical catalogue of agent-workflow risks, warning signs, and integration controls.
Source-backed Q&A
Governance Q&A
Search source-backed answers about receipts, signatures, audit evidence, and product scope.
Dated evidence review
Claims & Evidence
A dated source, release, CI, and limitations index for the product family.
Questions before evaluation
Before you get started.
Does this replace my existing agent framework?
The focus is the tool execution boundary. Evaluate the documented adapter or hook for your framework and confirm that every tool path you intend to govern actually passes through it.
Is this a managed production service?
The local runtime and Python package are evaluation starting points. Check their current release status and limitations. Hosting, identity, key management, storage, and operational controls require a deployment-specific assessment.
What does a decision receipt prove?
A receipt records a policy decision about a request. Its authenticity and enforceability depend on verification, action binding, and the integrating executor. A receipt alone does not prove that an external action succeeded or that a deployment meets compliance requirements.