Skip to content

security

Intended Documentation

Operational Readiness

Verify Intended is healthy and its audit integrity holds before going live — liveness/readiness probes, a token round-trip, audit-chain verification, and a pre-launch checklist grounded in real endpoints.

intermediate5 min readimplemented

Operational Readiness#

Before routing production AI workloads through Intended, confirm two things: the service is reachable and healthy, and its audit integrity holds. This guide uses only endpoints and commands that exist in the platform today; where a richer readiness suite is planned, it is marked Roadmap.

Prerequisites#

  • A configured tenant with at least one active policy.
  • API credentials (intended_live_…) with the permissions for the routes below — at minimum intent:create for the round-trip and audit read access for chain verification.
  • The Intended CLI installed (@intended/cli).
  • Network egress from your deployment environment to the Intended API on port 443.

Tip

Run these checks from the same network zone as your production workloads. A partition between your services and Intended is a common cause of false readiness — the API is healthy, but your workloads cannot reach it.

Health and readiness probes#

Intended exposes two unauthenticated operational endpoints. They are part of the public skip-auth path set, so you can probe them without a credential.

ProbeEndpointUse it for
LivenessGET /healthIs the process up and serving?
ReadinessGET /readyIs the process ready to accept traffic (dependencies wired)?
bash
# Liveness
curl -fsS https://api.intended.so/health

# Readiness — gate traffic on this in your orchestrator
curl -fsS https://api.intended.so/ready

Note

There is no public multi-service health roll-up endpoint and no intended health --all CLI command. Probe /health and /ready directly, and rely on your own observability stack for per-dependency health. Roadmap: a consolidated readiness command.

Authority round-trip#

Exercise the full decision-to-token path with a synthetic intent, then verify the token locally. This confirms the policy engine, token signing, and verification all agree end to end.

Submit a synthetic intent

Use a low-risk, clearly-allowed intent so the expected outcome is APPROVED (200).

bash
intended intent-submit \
  --tenant "$TENANT_ID" \
  --actor svc-readiness-probe \
  --action "readiness probe — no-op"

A non-APPROVED result for an intent you expect to pass means your active policy set does not yet permit it — resolve before going live.

Inspect the issued token

Decode the returned Authority Token to confirm its claims and TTL.

bash
intended inspect-token --token "$AUTHORITY_TOKEN"

Confirm decision is APPROVED, the tenantId/adapterId are correct, and exp is within 300 seconds of iat.

Verify the token signature

Verify the Ed25519 signature against the tenant public key, pinning the kid.

bash
intended verify \
  --token "$AUTHORITY_TOKEN" \
  --key tenant-public.pem \
  --kid "$KID" \
  --tenant "$TENANT_ID"

A successful verify confirms the signing key, the verifier, and clock alignment are all consistent.

Audit integrity verification#

A readiness gate should confirm the audit chain is intact, not just that records exist. Verify the per-tenant SHA-256 hash chain:

bash
curl -H "Authorization: Bearer $INTENDED_API_KEY" \
  -H "x-tenant-id: $TENANT_ID" \
  "https://api.intended.so/tenants/$TENANT_ID/audit/chain-verification"

Treat a valid: true response with the expected totalEntries as the pass condition. Any valid: false with a brokenAt index is a stop-ship integrity failure — see Enforcement Lineage.

You can also confirm recent events are landing:

bash
intended audit-query --tenant "$TENANT_ID" --limit 5

Pre-launch checklist#

Configuration#

  • [ ] Production tenant ID and intended_live_… credentials are configured
  • [ ] At least one active policy is deployed for the tenant
  • [ ] The synthetic authority round-trip returns the expected APPROVED outcome
  • [ ] Token TTL is the platform default of 300 seconds (it is also the hard maximum)

Networking#

  • [ ] /health and /ready are reachable from production workloads
  • [ ] TLS certificates are valid and not expiring within 30 days
  • [ ] Firewall rules permit egress to the Intended API on port 443
  • [ ] Any tenant IP allowlist includes your production egress addresses (else 403 IP_NOT_ALLOWED)

Audit & evidence#

  • [ ] audit/chain-verification returns valid: true with the expected entry count
  • [ ] An evidence bundle can be exported for a test intent (intended audit-export)
  • [ ] Evidence verification is understood to require the tenant secret (symmetric HMAC — see Enforcement Lineage)

Security#

  • [ ] API keys are injected from a secrets manager, never committed to code or images
  • [ ] Keys are scoped to the minimum permissions they need
  • [ ] Fail-closed behavior is understood: a 500 AUTHORITY_LOOP_FAILED is a denial, not a retryable allow

Rollback#

  • [ ] A rollback procedure is documented and tested (policy rollback through the audited pipeline)
  • [ ] On-call is briefed on Intended failure modes and the meaning of AUTHORITY_LOOP_FAILED

Warning

Do not proceed to production if the authority round-trip or chain verification fails. Each failure indicates a gap that surfaces in production as unexpected denials (fail-closed) or, worse, an integrity problem in the audit record.

Continuous readiness#

Readiness is not a one-time gate. Re-run the chain verification and a synthetic round-trip on a schedule, and alert on any valid: false chain result or any unexpected 500 AUTHORITY_LOOP_FAILED rate. Wire /ready into your orchestrator so unhealthy instances are pulled from rotation automatically.

Operational Readiness | Intended