Security orchestration as an authorized feedback controller

A security orchestrator observes a changing system, selects an intervention, applies it through enforcement points, and watches the result. That makes it a feedback controller. Because its outputs can revoke credentials, isolate workloads, reduce grants, require stronger authentication, or stop new leases, it is also a privileged actor.

Design rule: the controller may propose a security action; it may not bypass the same identity, policy, tenant, freshness, and scope checks imposed on other privileged actors.

Closed-loop model

Observe → decide → authorize → enforce

Fail closed

Rendering diagram…

1. Model the system before automating it

Use a discrete-time model. At step k, let the protected system state be:

X_{k} = (R_{k}, G_{k}, L_{k}, H_{k}, T_{k})

R_kresources and their security-relevant configuration

G_kactive grants, roles and policy bindings

L_ksessions, credentials, tokens and leases

H_kworkload, identity and control-plane health

T_ktenant ownership and isolation relationships

The controller rarely sees X_k directly. It receives an observation:

y_{k} = h (X_{k}) + ν_{k}

Here h is the measurement process—logs, identity events, configuration snapshots, traces, posture signals and alerts—and ν_k represents missing, delayed, duplicated, corrupted or noisy telemetry. Treating observations as perfect state is the first modelling error to avoid.

Symbols and implementation counterparts

Symbol	Meaning	Typical implementation
`X`_k	Security-relevant system state	Resource graph, IAM bindings, session store, workload inventory
`y`_k	Observation available to the controller	Normalized event plus correlated state snapshot
Π_k	Policy and its exact version	Signed policy bundle, revision and rollout metadata
`u`_k	Candidate action	Typed command: revoke, quarantine, step-up, deny-new-leases
ω_k	External disturbance	Attacker action, failure, deploy, scaling event, administrator change
`d`_k	Authorization decision record	Permit/deny, scope, reason, policy revision, expiry, evidence

2. Close the loop

Let the information available at step k be the observation history and the current policy:

I_{k} = (y_{0}, \dots, y_{k}, Π_{k})

The controller proposes an action from that information:

u_{k} = 𝒞 (y_{0}, \dots, y_{k}, Π_{k})

The system then evolves under the applied action and the external disturbance:

X_{k + 1} = ℱ (X_{k}, {\tilde{u}}_{k}, ω_{k})

The tilde matters: u_k is only a proposal. The plant receives ũ_k, the action that survives authorization and enforcement.

3. Put an authorization guard in front of the controller

Define an authorization guard A that evaluates the controller identity, requested operation, target tenant, target resource, policy revision and current preconditions. Here X̂_k is the freshest state the authorizer can observe under the declared consistency contract:

a_{k} = A (u_{k}, {\hat{X}}_{k}, Π_{k}) \in {0, 1}

The command delivered for enforcement is therefore:

{\tilde{u}}_{k} = {\begin{cases} u_{k} & if a_{k} = 1 \\ u^{\emptyset} & if a_{k} = 0 \end{cases}

u^∅ is a safe no-op or a fail-closed transition. It must not silently become “execute anyway and alert later.”

Authorization predicate

Apply (u_{k}) \Rightarrow \begin{array}{l} ControllerAuthenticated \\ \land ActionAuthorized (u_{k}) \\ \land TenantScopeValid (u_{k}) \\ \land PreconditionsSatisfied (u_{k}) \end{array}

What the guard must bind

A permit should bind at least the controller identity, action type, tenant, resource set, permitted effect, policy revision, evidence revision, issue time, expiry time, preconditions and an idempotency key. A valid signature over an under-specified command is not adequate authorization.

{
  "decision_id": "dec_01…",
  "controller": "security-orchestrator/prod",
  "action": "revoke_session_family",
  "tenant_id": "tenant-a",
  "resource_ids": ["user:1842"],
  "policy_revision": 417,
  "evidence_revision": 88031,
  "preconditions": ["session_epoch == 91", "risk_state == confirmed"],
  "not_before": "2026-09-14T10:12:20Z",
  "expires_at": "2026-09-14T10:12:50Z",
  "idempotency_key": "contain:incident-712:user-1842"
}

4. Containment must shrink authority

Let ℛ(X) be the set of protected effects reachable from state X: API calls, data reads, writes, role assumptions, token exchanges, network flows and lease creation. An action explicitly labelled containment must be non-expansive:

ℛ_{after} \subseteq ℛ_{before}

A useful containment action usually makes the inclusion strict. The weaker subset form permits an idempotent replay: revoking an already-revoked credential does not further shrink authority, but it also does not restore any.

Check the effect, not the action label. Moving a workload into a “quarantine” network that accidentally gains a new administrative path violates containment even if the command is named isolate.

Restoration is not the inverse edge

Restoration expands reachable effects. It is therefore a new authorization decision at a later time, not an automatic reversal when an anomaly score falls:

Restore (u^{- 1}, k^{'}) \Rightarrow NewPermit (k^{'}) \land \neg ScoreOnly

A falling anomaly score is evidence. It is not authority. Restoration should re-evaluate identity, policy, tenant, current resource state, incident disposition, credential lifecycle and required approvals. Expired or revoked authority stays dead unless a new grant is issued.

Security is a constrained control objective

Blindly minimizing reachable authority can destroy availability. A practical controller minimizes risk, disruption and control churn subject to hard safety and service constraints:

\min_{u_{k : k + N}} \sum_{i}^{k + N} [α Risk (X_{i}) + β Disruption (u_{i}) + γ Churn (u_{i})]

Rate limits, dwell times, hysteresis and human approval for high-blast-radius actions are not operational afterthoughts. They are mechanisms that prevent oscillation and unsafe over-correction.

5. Make tenant isolation a transition property

For tenants j ∈ 𝒯, represent the overall state as a product of tenant projections plus explicitly shared infrastructure:

X = (\underset{j \in 𝒯}{\times} X^{(j)}) \times X^{shared}

If action u is scoped to tenant t, every unrelated tenant projection should remain observationally equivalent to the no-op transition:

j \neq t (u) \Rightarrow {proj}_{j} (ℱ (X, u, ω)) ≃ {proj}_{j} (ℱ (X, u^{\emptyset}, ω))

Shared resources require an explicit coupling model. If isolating one tenant can exhaust a shared gateway, rotate a shared key or invalidate a shared cache, that cross-tenant effect belongs in the declared action scope and blast-radius review. It must not remain an invisible side effect.

6. Choose a consistency contract

Authorization is evaluated against distributed state: policy replicas, identity stores, revocation indexes, caches, resource versions and enforcement points. “The controller was authorized” is incomplete unless the system defines which version of that state counted.

Contract A

Strict authorization

With monotonically ordered authorization revisions, at a defined serialization point τ(q), the effect uses a decision based on a revision at least as new as the required revision for request q.

rev (d) \geq requiredRev (q, τ (q))

Use this where post-revocation effects are unacceptable and the latency cost is justified.

Contract B

Bounded stale authorization

Permit a decision from a snapshot no older than Δ_auth, then state the maximum exposure window explicitly.

now - snapshotTime (d) \leq Δ_{auth}

A conservative revocation bound is W ≤ Δprop + Δcache + Δin-flight. Measure all three terms; do not call the system “eventually consistent” and leave the risk unbounded.

Google’s Zanzibar paper is useful here because it treats authorization consistency as a system property, including causal ordering and externally consistent decisions, rather than as a cache implementation detail. The exact mechanism need not be copied; the discipline should be.

7. Verify the protected effect, not merely the decision

The central safety property connects the request, the decision actually enforced, and the resulting protected effect. Here q is a protected request and t is its effect time:

\forall q, t : ProtectedEffectExecuted (q, t) \Rightarrow ValidEnforcedPermit (q, t) \land EffectWithinAuthorizedScope (q, t)

This is stronger than “the policy engine returned permit.” It requires proof that the PEP enforced the intended decision, that the decision was valid at the chosen consistency point, and that the observed side effects stayed inside the decision’s scope.

Expanded permit validity predicate

\begin{array}{l} ValidEnforcedPermit (q, t) ≜ \\ Decision (q) = Permit \\ \land ControllerAuthenticated (q) \\ \land ActionAuthorized (q) \\ \land TenantScopeValid (q) \\ \land PolicyFreshEnough (q, t) \\ \land PreconditionsSatisfied (q, t) \\ \land NotBefore (q) \leq t < ExpiresAt (q) \\ \land PEPBoundToDecision (q) \\ \land ReplaySafe (q) \end{array}

NIST SP 800-207 separates the logical policy engine, which decides; the policy administrator, which establishes or terminates the communication path; and the policy enforcement point, which enables, monitors and terminates the connection. Those roles can be colocated or replicated, but the proof obligations remain distinct.

8. Translate the model into software contracts

A practical implementation can preserve the model without turning every service into a control-theory project. The important move is to make proposals, decisions, commands and effect receipts distinct records.

Normalize observations. Attach tenant, subject, resource, event time, ingestion time, source integrity and evidence revision.
Build a candidate action. Make it typed, deterministic for the same input, bounded in scope and safe to retry.
Authorize at execution time. Evaluate controller identity, action, tenant, resource, policy revision, current preconditions and decision lifetime.
Enforce through a narrow adapter. The PEP accepts only signed or mutually authenticated commands with an explicit schema and allowlist.
Return an effect receipt. Record the actual changed resources, previous and resulting versions, partial failures and enforcement time.
Observe again. Confirm the intended state transition. A successful API response is not proof that the system reached the safe state.

def reconcile(observation, policy_revision):
    candidate = controller.propose(observation, policy_revision)
    decision = authorizer.evaluate(candidate, fresh_state=True)

    if not decision.permit:
        return audit.denied(candidate, decision)

    command = bind(candidate, decision, ttl_seconds=30)
    receipt = enforcement_point.apply(command)

    assert receipt.tenant_id == decision.tenant_id
    assert receipt.effects <= decision.authorized_effects
    return verifier.confirm(receipt)

Separate control planes by capability

Component	May do	Must not do
Detector	Produce evidence and confidence	Directly mutate protected state
Controller	Propose a bounded typed action	Mint its own authority
Policy engine	Decide using identity, policy and context	Assume enforcement occurred
Policy administrator	Issue or terminate the authorized command/path	Broaden the decided scope
PEP	Enforce and return a receipt	Accept ambiguous tenant or resource targets
Verifier	Compare intended and observed effects	Treat request acceptance as state convergence

9. Worked example: suspicious workload credentials

Assume a workload identity begins making unusual cross-service calls.

Observe. The detector correlates new egress destinations, a token exchange and an anomalous call graph. The observation is scoped to tenant A and workload W.

Propose. The controller requests deny_new_leases(W) and revoke_session_family(W). It does not request deletion, role changes or a tenant-wide network shutdown.

Authorize. Policy permits this controller to contain workload W in tenant A for 30 seconds, provided the workload generation and identity epoch still match the evidence.

Enforce. The identity PEP increments W’s session epoch; the lease PEP denies new grants. Each returns a versioned receipt.

Verify. Existing sessions fail revalidation, no new leases appear, unrelated tenant projections are unchanged, and ℛ_after ⊂ ℛ_before.

Restore deliberately. A later recovery workflow issues fresh workload credentials only after remediation evidence and a new permit. A lower risk score does not re-enable the old epoch.

10. Verification plan

Test the model at three levels.

Properties

State-machine tests

No protected effect without a valid permit.
Containment never expands reachable effects.
Replays are idempotent.
Restore always requires a new decision.

Distributed behaviour

Fault injection

Delay policy and revocation propagation.
Duplicate and reorder commands.
Expire a decision during enforcement.
Partition the controller from one PEP.

Isolation

Tenant proofs

Generate cross-tenant identifiers.
Exercise shared-resource coupling.
Compare effect receipts with permit scope.
Alert on missing tenant attribution.

Trust anchors: identity issuers, policy authorities, signing and encryption keys, clocks, enforcement components and the evidence path used to verify effects. Compromise of one of these components changes what the invariant can guarantee; the threat model must say so explicitly.

Sources and further reading

NIST SP 800-207: Zero Trust Architecture — the logical policy engine, policy administrator and policy enforcement point model.
NIST SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments — identity-tier and network-tier enforcement for cloud-native systems.
Zanzibar: Google’s Consistent, Global Authorization System — causal ordering and external consistency for authorization decisions.
RFC 7009: OAuth 2.0 Token Revocation — a concrete standards-track revocation mechanism and its security considerations.

From model to evidence

Can your automation prove what it changed?

A useful security review should connect controller identity, policy revision, enforcement receipts, tenant scope and post-action evidence—not stop at a diagram or a successful API response.

Get a free Drift Audit →