Incidents and access revocation

Readiness

Before the pilot, operations must assign incident ownership, an on-call route, pilot organization contacts, a secure evidence location, severity criteria, and communication/escalation timing. Exercise them in the Phase 8 tabletop. This document does not invent customer contacts or contractual response times.

Respond

1. Record an incident ID, detection time, symptoms, affected organizations/apps/environments, and trace/request IDs. Preserve append-only audit history.
2. Establish scope using redacted telemetry: identity abuse, cross-tenant access, malicious build/runtime behavior, secret exposure, policy bypass, data corruption, or availability failure.
3. Contain at the narrowest effective boundary: revoke grants/sessions, suspend a route/app, deny an integration/egress capability, isolate a workload/cluster, or pause builds/deployments.
4. Escalate suspected isolation failure to platform security. Preserve relevant evidence without copying production bodies, tokens, raw secrets, or sensitive personal data into support tools.
5. Select a reviewed recovery path: compatible artifact rollback, isolated DB restore, key rotation, or cluster reconstruction. Record the human decision and possible data loss.
6. Validate policy, identity, tenant boundaries, app behavior, and monitoring before restoring normal access.
7. Record resolution, impact, timeline, corrective actions, owners, and follow-up tests. Corrections to audit records create new events.

User deactivation

On SCIM deactivation or an authorized access-removal event, disable the organization membership; revoke console and app access/sessions according to the documented revocation bounds; revoke MCP grants and developer credentials/direct Git access. Reconcile group/role removal and pending operations. Test that revoked access fails.

Retain historical attribution. Keep production applications organization-owned and running according to policy; reassign or flag missing business/technical owners and alert administrators. Do not delete apps merely because their creator leaves.

Provider and edge outages

For AI vendor failure, protect existing apps and use the approved manual maintenance path; AI availability is not a prerequisite for serving immutable deployments. For an edge-path outage, follow the validated recovery design without exposing an unauthenticated origin. For control-plane connectivity loss, apply the documented cache freshness, revocation, and fail-closed policy; those bounds must be established before the pilot.

Pilot data boundary

If regulated data is discovered, contain access and involve the organization's designated security/privacy contacts under the agreed incident process. Do not copy it into AI prompts, ordinary logs, or support records. A future regulated tier requires the separate controls described in the pilot regulated-data boundary.