Named reference journeys (GitHub, files/storage, email, Slack, customer data, cloud and database) have evidence only at their recorded scope; live vendor execution is not certified. This does not change enforcement of exact requests through enrolled managed MCP :call. See Scope and Limits.

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

Keel refuses unknown and unmapped tools at its platform safety floor (platform_safety_floor.unknown_action). No project policy can allow them.

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, Guided Read only adds a restriction rule. It does not create positive authority: add an independently bounded positive grant where appropriate, or use Technical mode to author the explicit policy below. Save the policy as the active project policy. This requires Production or Enterprise: Starter’s Basic authoring cannot use allow, the exists operator, or the context._keel.action_access_* fields, so Starter cannot express a read-only policy.

Read-only means:

• explicitly allow action_access_level values none and read — Keel executes only what a matching allow rule authorizes, so a policy with no allow rule denies every request, reads included
• deny write and admin
• give no positive grant to unknown, missing classification, or non-empty action_risk_tags; restriction rules may additionally record REVIEW

For harmless classified reads, this Technical-mode example supplies explicit positive authority. It is not the output of the Guided read-only compiler:

{
  "name": "Action access: read only",
  "rules": [
    {"if": {"not": {"field": "context._keel.action_access_level", "op": "exists", "value": true}}, "action": "require_human_review"},
    {"if": {"not": {"field": "context._keel.action_risk_tags", "op": "exists", "value": true}}, "action": "require_human_review"},
    {
      "if": {
        "any": [
          {"field": "context._keel.action_risk_tags", "op": "contains", "value": "code_exec"},
          {"field": "context._keel.action_risk_tags", "op": "contains", "value": "data_export"},
          {"field": "context._keel.action_risk_tags", "op": "contains", "value": "egress_external"},
          {"field": "context._keel.action_risk_tags", "op": "contains", "value": "pii_access"},
          {"field": "context._keel.action_risk_tags", "op": "contains", "value": "refund"},
          {"field": "context._keel.action_risk_tags", "op": "contains", "value": "spend"},
          {"field": "context._keel.action_risk_tags", "op": "contains", "value": "value_movement"}
        ]
      },
      "action": "require_human_review"
    },
    {"if": {"field": "context._keel.action_access_level", "op": "eq", "value": "unknown"}, "action": "require_human_review"},
    {"if": {"field": "context._keel.action_access_level", "op": "in", "value": ["write", "admin"]}, "action": "deny"},
    {"if": {"all": [{"field": "context._keel.action_access_level", "op": "in", "value": ["none", "read"]}, {"field": "context._keel.action_risk_tags", "op": "eq", "value": []}]}, "action": "allow"}
  ]
}

This grant requires both a classified harmless read and an explicitly empty risk-tag list. Missing, null, malformed, or non-empty tags do not satisfy it. Risk-tagged and unknown requests have no grant in this example; approval cannot release them. The platform safety floor also refuses unknown actions. If a project needs a reviewable consequential action, give that action its own bounded grant with all required trusted facts. Use deny instead of REVIEW when the restriction should record outright refusal.

If read/write fields are not enabled for a project, Keel rejects active policies that reference them. An allow rule whose condition can match unknown is a policy validation error (unclassified_action_cannot_allow); rules that match unknown must review, deny, or throttle.

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 is refused, while a mutating tool misclassified as read could fail open.

Related Pages

• Policy Conditions
• Trusted Action Fields
• Policy Reference
• How Keel Executes Authorized Actions
• Scope and Limits
• Platform Surfaces