# Rollout, monitoring, and incident response

Operate the integration, respond to non-enforcement, and preserve a practical recovery and exit path.

Updated: 2026-09-22

Canonical: https://docs.kastra.ai/security/operations

## 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](https://docs.kastra.ai/security/evaluation).

## 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](https://docs.kastra.ai/approvals/notifications) and [webhooks](https://docs.kastra.ai/approvals/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](https://docs.kastra.ai/reference/failure-behavior) documents the detailed paths.

## Appliance operations

The self-hosted enterprise appliance is coming soon. Its operating model preserves runtime policy enforcement and approval/resume through license expiry, while limiting authoring and licensed configuration. Existing active members retain configured SSO access. Plan for local owner recovery, working email delivery, approved network dependencies, and tested backup and restore procedures. Explore the [self-hosted overview](https://docs.kastra.ai/reference/self-hosted) to discuss an operating scope with Kastra.

## 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](https://kastra.ai/contact). Use [vulnerability disclosure](https://kastra.ai/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.