Rollout, monitoring, and incident response

Prepare a controlled rollout

Assign an integration owner, policy owner, approver group, and incident contact. Record the tested client versions, active revision, environment, required entitlements, and approved data scope. Retain the previous policy revision and the steps for restoring it.

Start with a small cohort and inspect real outcomes before expanding. Re-run the acceptance cases after changing an agent version, hook configuration, proxy client, policy, or provider path. Pilot plan.

Monitor the state that matters

Signal	Operational question	Response
Expected action has no matching decision	Was the hook invoked or the request routed through Kastra?	Check the exact action, path, version, environment, and supported cache behavior
Fail-open event or evaluation error	Did the action continue without a policy decision?	Apply the accepted failure runbook; investigate reachability, authentication, parsing, or host timeout
Pending or expired checkpoints	Is approver coverage adequate and is the timeout outcome appropriate?	Inspect stored state and delivery, then review staffing and policy scope
Increased denials or false positives	Did policy or the integration’s input shape change?	Compare revisions and examples; retest a proposed correction before activation
Failed webhook delivery	Does the receiver have the event it needs?	Inspect delivery records and retry/deduplication behavior; use checkpoint state for approval status
Hosted billing-driven observe-only	Has blocking enforcement stopped after a trial or subscription lapse?	Escalate to the workspace owner and confirm restoration with a safe control test

Some signals require an operator check or your own monitoring process. Configure the supported notification rules and webhooks for the events you need; do not assume every row is a built-in alert.

Distinguish availability from enforcement

Edge and local MCP can allow work to continue during some failures. Server refusal to record a decision is a different boundary and can return an error that the client handles according to its own policy. An operation completing is therefore insufficient evidence that it was authorized normally.

Deliberate shadow mode and billing-driven observe-only also permit non-enforced work for different reasons. Keep those states visible in operational reviews. The failure guide documents the detailed paths.

Appliance operations

Self-hosted license expiry has a different contract from hosted subscription expiry: authoring/configuration becomes limited while runtime policy enforcement and approval/resume continue. Existing active members retain configured SSO access for renewal. Confirm license status, local owner recovery, real email delivery, approved network dependencies and a tested restore procedure. Development candidates already exercise packaged installation, SMTP, recovery activation and an exact assisted upgrade pair. The final customer profile, release trust/delivery, capacity and complete operator handoff remain open. Follow the self-hosted deployment guide when agreeing on an operating scope.

Investigate an incident

Capture the timestamp, request or tool-use ID, integration and version, workspace/environment, policy revision, response, checkpoint state, and observed side effect. Preserve the relevant decision and administrative audit records with their verification scope.

If the workflow must stop immediately, use the access and isolation controls appropriate to the underlying application or system. A Kastra credential revocation alone does not guarantee that a fail-open client stops executing tools.

Share sanitized identifiers through Kastra support. Use vulnerability disclosure for a suspected security vulnerability. Response-time, support-coverage, and incident-notification commitments come from the applicable agreement.

Recovery and exit

Restore a known policy revision, fix the integration, and repeat an allow/block/HOLD check before expanding access. Record the cause and residual risk.

Before ending the deployment, export the permitted evidence your retention policy requires, revoke applicable keys and grants, remove managed integrations using their documented removal steps, and confirm the new request path. Agree on deletion and retention handling through the privacy and contractual process. This provides a reviewable exit without treating the absence of telemetry as proof of offboarding.