The decision process Cedar uses to determine whether a request should be allowed or denied. It evaluates policy statements against principals, actions, and resources, and in this context it can use MCP tool annotations as resource attributes when those attributes exist.
Expanded Definition
Cedar policy evaluation is the authorization decision step that turns policy text into an allow or deny result for a specific request. In an NHI context, the request usually comes from an agent, service account, or workload identity, and the evaluation compares the principal, action, and resource against the policy’s conditions. Cedar is intentionally explicit about these inputs, which makes it useful when an organisation needs predictable, machine-readable authorization logic instead of ad hoc app code. The policy language is documented by NIST Cybersecurity Framework 2.0 style governance expectations around access control, even though Cedar itself is not a NIST control framework.
Where usage is still evolving is the treatment of dynamic attributes. In agentic systems, teams sometimes pass MCP tool annotations into evaluation as resource attributes when those annotations exist, but no single standard governs this yet. That means implementers must be precise about which attributes are trusted, which are derived at runtime, and which are merely descriptive metadata. Cedar evaluation is therefore not the same as policy authoring, and it is not the same as identity proofing. The most common misapplication is treating evaluation as a substitute for upstream identity validation, which occurs when teams trust request context without first verifying the calling NHI.
Examples and Use Cases
Implementing Cedar policy evaluation rigorously often introduces a latency and governance tradeoff, requiring organisations to balance fine-grained authorization against the operational cost of maintaining accurate attributes and policy updates.
- A build agent requests access to a deployment resource, and Cedar allows it only when the workload identity, environment, and action match the policy conditions.
- An AI agent invokes a tool through MCP, and the evaluator uses tool annotations as resource attributes to decide whether the action is permitted.
- A service account attempts to read a secrets manager path, and policy evaluation denies access unless the principal is in an approved role and the resource is tagged for that workload.
- During a platform migration, teams use Cedar evaluation to centralize authorization rules that were previously scattered across application code and infrastructure scripts.
- A security team reviews Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs alongside Cedar logs to ensure policy decisions reflect current entitlement and offboarding state.
For additional context on the control surface, practitioners often pair Cedar with the Top 10 NHI Issues, since authorization logic becomes more reliable when secret handling, rotation, and visibility are already under control.
Why It Matters in NHI Security
Cedar policy evaluation matters because NHI compromises are rarely about a single broken login; they are usually about a valid identity being allowed to do too much. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes authorization decisions a high-value control point. If evaluation logic is too permissive, stale, or based on untrusted attributes, an attacker who steals a token can move laterally, invoke tools, or reach sensitive resources without triggering obvious authentication failures.
The governance value is that Cedar makes decision logic inspectable. Security teams can review why a request was denied, align rules to least privilege, and connect runtime decisions to audit expectations described in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. That is especially relevant when agent workflows blend human approvals, workload identities, and tool-mediated actions. Organisations typically encounter authorization drift only after a compromised identity, unexpected tool call, or overbroad service account access is discovered, at which point Cedar policy evaluation 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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Policy evaluation enforces least privilege for NHIs at request time. |
| OWASP Agentic AI Top 10 | A-03 | Agent tool access depends on explicit authorization decisions. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed according to least-privilege principles. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires explicit, continuous authorization decisions. |
| NIST AI RMF | AI systems need governed, traceable decisions for accountable use. |
Review Cedar rules against entitlements regularly and remove any request paths that exceed role need.
Related resources from NHI Mgmt Group
- What is the difference between policy evaluation and vector filtering in RAG?
- What should organisations do when policy evaluation becomes too slow?
- Why does data-shape fit matter so much in policy evaluation systems?
- How should teams decide whether policy evaluation belongs in kernel space or user space?
