SA-8(15): Predicate Permission

SA-8(15) requires you to implement “predicate permission” as a security design principle: access must be granted only when explicit, verifiable conditions (predicates) are satisfied at the time of the request, not just because a user has a role. To operationalize it, define the predicates for sensitive actions, enforce them in your authorization layer, and retain evidence that the predicates are implemented, tested, and reviewed. ¹

Key takeaways:

• Define “predicates” for high-risk actions (data access, admin changes, key operations) and make them machine-enforced, not policy-only. ¹
• Build authorization rules that evaluate context (resource, action, environment, time, device, session, approvals) at runtime and fail closed. ¹
• Keep assessor-ready artifacts: predicate catalog, rule code/config, test results, and change history tied to system design decisions. ¹

The sa-8(15): predicate permission requirement sits in the System and Services Acquisition (SA) family because it’s fundamentally a design decision: you build systems so permissions depend on conditions that must be true right now, for this request, against this resource. That is different from “the user has the role, so allow it.” Predicate permission pushes you toward explicit authorization logic, attribute-aware decisions, and guardrails that reduce ambient authority.

Compliance teams struggle with SA-8(15) for one reason: it’s easy to describe and hard to prove. Auditors will look for concrete implementation details in architecture, code or platform configuration, and repeatable evidence that the principle is applied consistently to sensitive workflows. If you only have a policy statement, you will not be able to show implementation.

This page gives requirement-level guidance you can execute quickly: scope what “predicate permission” means in your environment, define predicates for your highest-risk actions, enforce them through an authorization mechanism, and generate evidence artifacts that map cleanly to NIST SP 800-53 assessments. ¹

Regulatory text

Control requirement (verbatim): “Implement the security design principle of predicate permission in {{ insert: param, sa-08.15_odp }}.” ¹

Operator interpretation: You must design and implement authorization so that permission is contingent on evaluated predicates (explicit conditions) rather than being implied by broad grants. In practice, your system should compute an allow/deny decision by checking required predicates for the requested action (for example, “ticket approved,” “device compliant,” “time window valid,” “resource owner matches,” “MFA present,” “data classification allowed,” “break-glass recorded”). You then need evidence that this design principle is actually enforced for your in-scope system functions. ¹

Plain-English interpretation (what predicate permission means)

Predicate permission means “no access unless conditions are true.” Those conditions must be:

• Explicit: written down as rules for each sensitive action.
• Verifiable: the system can evaluate them (attributes, signals, states).
• Enforced at decision time: checked each time, not assumed from earlier steps.
• Fail-closed: if the system cannot evaluate a predicate, deny by default.

Think of it as converting “who you are” (identity/role) into “what you can do right now” (contextual authorization). Roles can still exist, but they are not sufficient for high-impact actions without predicate checks.

Who it applies to

SA-8(15) commonly applies in these contexts:

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or via an assessment boundary. ¹

Operationally, it applies wherever your system makes authorization decisions:

• Applications (web, mobile, thick clients)
• APIs and service-to-service calls
• Administrative consoles and cloud control planes
• Data platforms (query access, export, sharing)
• CI/CD and infrastructure automation (who can deploy, change configs, rotate keys)

What you actually need to do (step-by-step)

1) Pick the “sensitive actions” where predicates are mandatory

Start with actions that create irreversible harm or broaden access. Create an initial list such as:

• Create/modify identities, roles, policies
• Read/export regulated datasets
• Change logging, monitoring, or retention settings
• Rotate/disable encryption keys, secrets, certificates
• Approve payments, transfers, or workflow releases (if applicable)
• Create external shares, public links, cross-tenant access

Deliverable: Sensitive Action Register (table) with owner, system component, and current authorization method.

2) Define predicates per sensitive action (write them as testable rules)

For each action, define a minimal set of predicates. Examples you can adapt:

• User predicate: user is in an approved group and has completed MFA this session.
• Resource predicate: resource classification is within user’s clearance, and tenant matches.
• Workflow predicate: change request is approved, not expired, and linked to the deployment.
• Device/session predicate: device posture compliant; session age below your threshold; step-up auth performed.
• Environment predicate: action allowed only from corporate network or managed CI runner.
• Time predicate: allowed only during change window, or requires break-glass outside hours.

Deliverable: Predicate Catalog (by action) written in “IF… THEN allow” form, with data sources for each predicate (IdP claims, CMDB tag, ticket status, device posture feed).

3) Decide where enforcement lives (centralize if you can)

Choose an enforcement approach that reduces drift:

• Central policy engine (preferred when multiple services need consistent rules)
• Gateway/API authorization layer for APIs
• Platform-native controls (cloud IAM conditions, database row-level security, SaaS conditional access)
• Application-layer authorization with shared library and mandatory checks

Your goal: one place to audit, test, and change predicates without hunting across services.

Deliverable: Authorization Architecture Note that shows decision points, inputs (attributes), and outputs (allow/deny + reason).

4) Implement runtime evaluation and fail-closed behavior

Engineering requirements you should insist on:

• Predicates are evaluated on every request for in-scope actions.
• Default deny when attributes are missing or systems are unavailable.
• Authorization decisions are logged with enough detail to support investigation (action, resource, principal, evaluated predicates, outcome), without leaking sensitive data.

Deliverable: Implementation evidence (config export, policy-as-code repo link, screenshots for managed platforms) plus sample authorization logs.

5) Test predicates like security controls, not like features

Minimum test coverage for SA-8(15):

• Positive tests: allowed only when each predicate is satisfied.
• Negative tests: denied when any predicate fails.
• Tamper tests: attempt to bypass enforcement (direct API call, stale token, missing claim).
• Regression tests: predicates remain enforced after changes.

Deliverable: Predicate Permission Test Report (automated test output + brief narrative).

6) Put predicates under change control with periodic review

Because predicates encode risk decisions, treat them like a control:

• Document who can change predicate rules.
• Require review/approval for predicate changes affecting high-risk actions.
• Review predicates on a cadence aligned to your change governance and system risk profile.

Deliverable: Change records tied to predicate updates, plus a review log showing the last review and outcomes.

7) Map SA-8(15) to an accountable owner and recurring evidence

Assign a control owner (often security architecture or platform security) and define “evidence you can produce on demand.” Daydream can help by turning SA-8(15) into a control record with an owner, a procedure, and an evidence schedule so audits do not turn into a scavenger hunt. ¹

Required evidence and artifacts to retain (assessor-ready)

Keep these artifacts in a single audit package:

1. Sensitive Action Register (scope + rationale).
2. Predicate Catalog (rules per action, attribute sources, fail-closed behavior).
3. Architecture diagram / authorization flow (where decisions happen).
4. Policy/code/config evidence (policy-as-code, IAM conditions, app authorization module references).
5. Test evidence (CI results, screenshots, test cases, penetration notes for bypass attempts).
6. Authorization logging samples (representative events showing predicate evaluation outcomes).
7. Change management evidence (PRs, approvals, tickets, release notes for predicate changes).
8. Exception register (where predicate permission is not feasible yet, with compensating controls and target remediation).

Common exam/audit questions and hangups

Auditors and assessors commonly press on:

• “Show me where the predicate is enforced.” They will not accept a policy statement alone.
• “How do you know this can’t be bypassed?” Expect questions about direct API calls, service accounts, and admin paths.
• “What happens if the attribute provider is down?” If the answer is “it allows,” you have a fail-open gap.
• “How do you keep predicates consistent across services?” Drift is a recurring finding.
• “How do you review and approve predicate changes?” Predicate rules are security logic.

Frequent implementation mistakes (and how to avoid them)

• Mistake: equating roles with predicates. Fix: require at least one non-role predicate for high-risk actions (approval state, device posture, resource tag, step-up auth).
• Mistake: predicates exist but are not enforced everywhere. Fix: identify all access paths (UI, API, CLI, batch jobs) and test each path explicitly.
• Mistake: fail-open on missing attributes. Fix: design for “deny on unknown,” plus an operational runbook for attribute outages.
• Mistake: predicates defined in docs but not traceable to code/config. Fix: store predicates with pointers to implementation locations and version history.
• Mistake: no evidence package. Fix: pre-build the artifact set above and refresh it as part of release governance.

Enforcement context and risk implications

No public enforcement cases are provided in the supplied sources for this requirement. ¹

Risk-wise, weak predicate permission increases the chance of:

• Privilege accumulation (users can do more than intended over time)
• Lateral movement and blast-radius expansion after credential compromise
• Unauthorized exports or administrative changes through overlooked access paths

Treat SA-8(15) as a guardrail against “ambient authority” in both human and service identities.

Practical 30/60/90-day execution plan

First 30 days (establish scope + design)

• Assign a control owner and publish a one-page SA-8(15) implementation standard.
• Build the Sensitive Action Register for the system boundary.
• Draft the Predicate Catalog for the highest-risk actions.
• Decide the enforcement points (policy engine, gateway, app layer, IAM conditions).
• Create the evidence checklist folder structure so artifacts land in the right place from day one.

Days 31–60 (implement + test)

• Implement predicates for the top actions in code/config, with fail-closed behavior.
• Add automated tests for predicate allow/deny paths.
• Add structured authorization logging for predicate decisions.
• Run a bypass review: confirm UI and API paths share the same authorization logic.

Days 61–90 (operationalize + audit-ready)

• Put predicate changes under change control (approval + review).
• Run an internal mini-assessment: trace 3–5 sensitive actions from policy to enforcement to logs.
• Capture a complete evidence package and store it in your GRC repository.
• Track exceptions with compensating controls and planned remediation.

If you manage many systems, Daydream can reduce overhead by standardizing the SA-8(15) control record, assigning owners, and generating recurring evidence requests tied to your audit calendar. ¹

Frequently Asked Questions

What counts as a “predicate” in SA-8(15)?

A predicate is a condition the system can evaluate at authorization time, such as an approval state, device posture, resource tag, time window, or step-up authentication. The key is that access depends on the predicate being true, not just on identity or role. ¹

Can we meet SA-8(15) with RBAC alone?

RBAC helps, but RBAC-only designs often miss contextual conditions (approval, device, environment, resource classification). For high-risk actions, document and enforce additional predicates beyond “user has role.” ¹

Where should predicate permission be implemented: app code or IAM?

Put predicates where they can be enforced consistently across access paths. For cloud and SaaS, IAM conditions and platform controls are strong options; for complex business logic, a centralized authorization service or shared library often works better. ¹

How do service accounts and machine identities fit into predicate permission?

Treat them the same way: define predicates for what the service can do and under what conditions (workload identity, environment constraints, signed deploy attestations, network location). Avoid broad long-lived credentials that bypass predicate checks. ¹

What evidence is most persuasive to an assessor for SA-8(15)?

A predicate catalog tied to specific enforcement points, plus test results proving deny behavior when predicates fail. Add change history showing predicates are reviewed and controlled like security logic. ¹

How do we handle exceptions where predicates aren’t feasible yet?

Record exceptions with scope, risk rationale, compensating controls, and a remediation plan. Auditors usually accept exceptions when they are explicit, time-bounded by your governance process, and tracked to closure. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON