Envoy ext_authz is an HTTP filter that pauses a request and asks an external authorization service for a decision before forwarding it. The filter can pass request metadata, apply allow or deny outcomes, and attach headers on success. It is an enforcement point, not a place to store business rules.
Expanded Definition
Envoy ext_authz is best understood as a policy enforcement checkpoint for service-to-service traffic, not as the policy source itself. In an NHI and agentic AI environment, it sits in the request path, pauses execution, and asks an external decision engine whether the request should proceed. That makes it useful when access decisions depend on attributes such as workload identity, request path, token claims, user context, or tool invocation risk. The distinction matters because the filter enforces an answer, while the authorization service defines the logic. For a standards-oriented view of access control and monitoring expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference, especially where systems must prove that authorization decisions are consistently enforced and logged.
Definitions vary across vendors on how much context the ext_authz service should receive and how much logic should live in the filter chain versus the backend policy engine. In practice, teams use it to externalize decisioning for APIs, service meshes, and agent tool calls without embedding authorization rules into application code. The most common misapplication is treating ext_authz as a policy store, which occurs when teams hard-code business rules into the authorization service and then couple deployment of policy changes to proxy configuration changes.
Examples and Use Cases
Implementing Envoy ext_authz rigorously often introduces latency and operational coupling, requiring organisations to weigh centralised control against the cost of every request depending on an external decision path.
- A workload presents a short-lived service credential, and the filter consults an authorization service before allowing access to a downstream API.
- An AI agent submits a tool call, and ext_authz checks whether the calling identity, prompt context, and destination service are permitted to interact.
- A mesh gateway passes headers and request metadata to a policy engine that denies requests missing required attestation or environment claims.
- A team uses ext_authz to add success headers that downstream services interpret for additional telemetry or routing decisions.
- During a rollout, the policy engine can block risky traffic from newly created NHIs until the accounts are approved and observed in monitoring, aligning with NHI governance guidance in the Ultimate Guide to NHIs.
This pattern is often paired with identity-aware service mesh controls and standards-based authorization design. For implementation detail on request mediation and policy evaluation, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog is a useful baseline for control objectives.
Why It Matters in NHI Security
Ext_authz matters because NHIs and AI agents routinely act faster than human operators can review, which makes every implicit permission a potential blast-radius multiplier. If the authorization boundary is weak, an attacker who compromises one token, certificate, or service account can move laterally through machine-to-machine pathways that look legitimate to downstream services. NHIMG research shows that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why request-time enforcement is not optional in mature NHI programs. The same governance gap appears when secrets and workload identities are assumed to be trustworthy simply because they are internal. Ext_authz helps force explicit decisions, but only if the external policy engine is fed with current identity context and revocation status. It should complement broader controls such as short-lived credentials, rotation, and visibility, not replace them. The Ultimate Guide to NHIs is especially relevant here because it frames the lifecycle failures that make authorization enforcement necessary in the first place. Organisations typically encounter unauthorized machine access only after a credential leak or compromised workload is observed, at which point Envoy ext_authz becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Ext_authz enforces request-time policy checks for machine identities and service-to-service access. |
| OWASP Agentic AI Top 10 | A-03 | Agent tool calls need policy enforcement before execution, which ext_authz can provide. |
| NIST CSF 2.0 | PR.AC-4 | This control covers access permissions and enforcement consistent with proxy-based authorization checks. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous decisioning at enforcement points like Envoy ext_authz. |
| NIST SP 800-63 | Identity assurance concepts inform whether a workload or agent credential is trustworthy enough to authorize. |
Gate every agent action with external authorization and block tool use without explicit policy approval.
