Skip to content

security

Intended Documentation

Operational Readiness

Run operational readiness checks before going live — health endpoints, validation scripts, and a pre-launch checklist.

intermediate5 min readimplemented

Operational Readiness#

Before enabling Intended for production AI workloads, run the operational readiness checks described in this guide. These checks verify that every component in the authorization chain is healthy, correctly configured, and behaving according to fail-closed expectations.

Prerequisites#

Before running readiness checks, ensure you have:

  • A configured Intended tenant with at least one active policy
  • API credentials with operator-level access
  • The Intended CLI installed (v1.0 or later)
  • Network access to all Intended service endpoints from your deployment environment

Tip

Run readiness checks from the same network zone as your production workloads. Network partitions between your services and Intended are a common source of false readiness.

Health Endpoints#

Intended exposes health endpoints for each core service. All endpoints return a standard health response.

Endpoint Overview#

ServiceEndpointExpected Status
API GatewayGET /healthhealthy
Policy EngineGET /healthhealthy
Token ServiceGET /healthhealthy
Audit ServiceGET /healthhealthy
Connector RuntimeGET /healthhealthy

Health Response Format#

json
{
  "status": "healthy",
  "version": "1.4.2",
  "uptime_seconds": 86421,
  "checks": {
    "database": "pass",
    "cache": "pass",
    "signing_key": "pass"
  }
}

A service is considered healthy only when status is healthy and all entries in checks are pass. A service reporting healthy with a failing sub-check should be investigated before proceeding.

Checking Health via CLI#

bash
meritt health --all

This command queries all service health endpoints and produces a summary:

API Gateway        healthy  v1.4.2
Policy Engine      healthy  v1.4.2
Token Service      healthy  v1.4.2
Audit Service      healthy  v1.4.2
Connector Runtime  healthy  v1.4.2

All services healthy. Ready for readiness validation.

Readiness Validation Script#

The CLI includes a built-in readiness validation that exercises the full authorization chain end-to-end.

Run the readiness check

Execute the readiness validation command:

bash
meritt ops readiness-check --tenant $TENANT_ID

This command performs the following checks automatically.

Policy evaluation round-trip

The check submits a synthetic intent and verifies that:

  • The policy engine evaluates it within the configured timeout
  • The evaluation result matches the expected outcome for the test policy
  • A decision token is issued and correctly signed

Token verification round-trip

The check takes the issued decision token and verifies that:

  • The token signature can be validated by the enforcement point
  • The token TTL is within expected bounds
  • The token claims match the evaluation result

Audit trail verification

The check confirms that:

  • The synthetic intent, evaluation, token, and enforcement events all appear in the audit log
  • The enforcement lineage chain is intact and verifiable
  • Audit events were recorded within acceptable latency (under 2 seconds)

Fail-closed verification

The check intentionally triggers a fail-closed scenario by:

  • Submitting an intent with an expired token
  • Verifying the enforcement point rejects it
  • Confirming the denial is recorded with the correct reason code

Review results

The command outputs a pass/fail summary:

Policy evaluation round-trip     PASS  (14ms)
Token verification round-trip    PASS  (8ms)
Audit trail verification         PASS  (1.2s)
Fail-closed verification         PASS  (6ms)

Operational readiness: PASSED

Warning

Do not proceed to production if any readiness check fails. Each failure indicates a gap in the authorization chain that could result in either unauthorized access or unexpected denials.

Pre-Launch Checklist#

Use this checklist to verify all operational concerns before enabling production traffic.

Configuration#

  • [ ] Tenant ID and API credentials are configured for the production environment
  • [ ] Policy engine has at least one active policy deployed
  • [ ] Decision token TTL is set appropriately (default: 5 minutes)
  • [ ] Circuit breaker thresholds are reviewed and accepted

Networking#

  • [ ] All Intended service endpoints are reachable from production workloads
  • [ ] TLS certificates are valid and not expiring within 30 days
  • [ ] DNS resolution for Intended endpoints completes within 100ms
  • [ ] Firewall rules permit egress to Intended API on port 443

Monitoring#

  • [ ] Health check endpoints are monitored by your observability stack
  • [ ] Alerts are configured for circuit breaker state changes
  • [ ] Alerts are configured for fail-closed denial rate spikes
  • [ ] Audit log export is configured to your SIEM (if required)

Security#

  • [ ] API keys are stored in a secret manager, not in environment variables or code
  • [ ] Operator credentials use short-lived tokens, not long-lived API keys
  • [ ] Enforcement lineage verification passes for all test scenarios
  • [ ] Fail-closed behavior has been validated with the readiness check

Rollback Plan#

  • [ ] A rollback procedure is documented and tested
  • [ ] The previous authorization mechanism can be re-enabled within your RTO
  • [ ] On-call team is briefed on Intended failure modes and escalation paths

Continuous Readiness#

Operational readiness is not a one-time check. Schedule periodic re-validation:

bash
# Run readiness check on a cron schedule
meritt ops readiness-check --tenant $TENANT_ID --output json | \
  meritt ops report --format summary

Info

Intended recommends running the readiness check at least once per deployment and daily in production. Integrate the check into your CI/CD pipeline as a post-deploy gate.