Read/Write Governance

Read/write governance lets a project decide which governed agent actions may proceed, which require human review, and which are denied. The control is a project policy over Keel-derived action facts: access level, risk tags, connector identity, classifier source, and registry version.

For governed routes, Keel records those facts on the permit/audit metadata. On supported plans, decision snapshots, signed exports, and Keel’s tamper-evident integrity stack can then show what Keel classified, which policy ran, and what decision Keel returned for the actions that routed through Keel. That is the proof boundary; it is not a claim that Keel governs every action an agent can take off path.

What Keel governs

Keel governs actions that route through a Keel decision boundary:

Keel does not govern direct calls the agent makes with its own provider, API, browser, database, or tool credentials. Browser and computer-use actions are coarse unless a concrete action is mediated by a governed Keel route or tool. On permit-first integrations, Keel records the decision before execution, but the caller still owns the downstream call and must honor the decision.

What Keel classifies

When action access is enabled for a project, governed policy context can include:

Caller-supplied context._keel values are stripped before evaluation. A caller can declare intent, but declared intent never grants access.

Access levels

Access level is one ordered ladder. unknown is not a rung; it is the fail-closed sentinel.

Risk tags

Risk tags are independent of access level. A read-only policy should check both the ladder and the tag set.

Fail-closed behavior

Read/write governance is intentionally conservative:

• unmapped or unknown tools classify as unknown
• unknown is not read-only safe and should review or deny
• policy authoring rejects active policies that allow unclassified actions
• low- or medium-confidence classifications do not become read
• generic MCP verb names such as read, list, get, or search are not trusted as read semantics by themselves
• database read/write classification comes from the credential scope Keel provisioned or verified, not from SQL parsing
• any risk tag, including a future tag, blocks read-only-safe classification

The default for unknown and unmapped tools is review. Projects can write stricter policies that deny them instead.

Enable read-only mode for a project

For eligible hosted projects, read/write controls are generally available. They do not change behavior until the project has an active policy that uses context._keel.action_access_* fields.

In the dashboard, create or edit a project policy in Guided or Technical mode. Choose the read-only access mode, or author an equivalent policy. Save it as the active project policy.

Read-only means:

• allow action_access_level values none and read
• review or deny write, admin, and unknown
• review or deny any non-empty action_risk_tags list

A read-only review policy has this shape:

{
  "name": "Read-only guardrail",
  "rules": [
    {
      "if": {
        "any": [
          {
            "field": "context._keel.action_access_level",
            "op": "in",
            "value": ["write", "admin", "unknown"]
          },
          {
            "field": "context._keel.action_risk_tags",
            "op": "len_gt",
            "value": 0
          }
        ]
      },
      "action": "require_human_review"
    }
  ]
}

Use deny instead of require_human_review when the project should block matching actions outright.

If read/write fields are not enabled for a project, Keel rejects active policies that reference them. A policy that can match unknown cannot use allow; for a read-only policy, use require_human_review or deny.

Coverage boundaries

Keel’s strongest read/write coverage is on surfaces where Keel is on the execution path or verifies the downstream credential scope.

The Stripe row describes action classification, not blanket execution coverage. Keel does not expose a first-class general Stripe refund rail. The exact stripe.refund.create action is Keel-enforced only when it uses an enrolled managed MCP :call contract. That beta/limited path has been demonstrated with genuine Stripe TEST refunds; the customer adapter owns the final Stripe HTTP call and TEST credential, live mode is not established, and direct Stripe calls with separate credentials bypass Keel.

Registry coverage is versioned and audited. The policy-authoring catalog reports project MCP coverage from the project’s configured tool allowlists, including the number of unknown tools. Missing entries are safer than wrong read entries: an unmapped tool reviews by default, while a mutating tool misclassified as read could fail open.

Related Pages

• Policy Conditions
• Trusted Action Fields
• Policy Reference
• Execution Architecture
• Scope and Limits
• Platform Surfaces