Authorization Glossary
Technical definitions for authorization concepts — RBAC, ABAC, scopes, deny-wins, and more. Written for engineers building access control systems.
Core Concepts
Authorization that evaluates permissions at the individual resource or action level, rather than broadly by user type or role.
Role-Based Access Control (RBAC) grants permissions via roles. Attribute-Based Access Control (ABAC) evaluates arbitrary attributes (user, resource, environment) against policy rules.
CNCF-graduated policy engine that evaluates policies written in Rego. Used for authorization across Kubernetes, microservices, and APIs. Requires learning a domain-specific language.
Authorization model where decisions are based on attributes of the subject, resource, action, and environment — evaluated against policy rules at request time.
Authorization model based on relationships between subjects and objects (e.g., owner, editor, viewer). Popularized by Google's Zanzibar paper. Access is resolved through graph traversal.
Google's global authorization system described in their 2019 paper. Uses relationship tuples and namespace configuration for ReBAC at planetary scale with single-digit millisecond latency.
Security principle that every subject should have the minimum access needed to perform its function — and no more. Foundation of zero trust and defense-in-depth architectures.
Authorization model where every request is verified independently — no implicit trust based on network location. "Never trust, always verify" applied to access control decisions.
Evaluation
An authorization evaluation rule where an explicit deny on any matching permission overrides all allow permissions. Used to enforce least-privilege without restructuring role hierarchies.
A permission where the resource or action component is *, matching any value. For example, invoice:* grants all actions on invoices; *:read grants read on all resources.
Security control that prevents a single user from performing conflicting operations. For example, the same person cannot both create and approve a payment — requires two distinct identities.
Immutable, chronological record of every authorization decision — who, what, when, scope, resource, action, and outcome. Enables compliance reporting and incident investigation.
Architecture
The authorization engine that evaluates access requests against policies and returns allow/deny decisions. The PDP is the "brain" — it owns the rules and logic.
Thin code in your application that intercepts requests and asks the PDP "is this allowed?" The PEP enforces decisions but does not own policy logic.
Architecture pattern where authorization logic is moved from application code to a dedicated service (PDP). Your app asks for decisions rather than embedding permission checks.
Managing authorization policies as version-controlled code artifacts rather than database records. Enables GitOps workflows: PR → review → merge → policy update via real-time sync (OPAL).
Agent Security
Security mechanism that scans tool descriptions, arguments, and results for prompt injection payloads before AI agents process them. Detects instruction-override patterns and hidden unicode.
Runtime scanning of data flowing through tool calls in both directions — secrets in arguments, PII in results, sensitive data patterns — with blocking or redaction before the agent sees it.
Security pattern requiring a human reviewer to approve sensitive operations before an agent executes them. Single-use approval consumed on the next matching call.
Monitoring for changes in MCP server tool signatures after approval — new tools added, tool schemas modified, endpoints changed. Alerts fire so teams can re-evaluate before the agent uses new tools.
Signed, verifiable proof tokens produced for every authorization decision. Non-repudiable audit trail that can be verified without trusting the authorization service.
Per-organization configurable rate limit that stops runaway AI agents before they flood external APIs. Token bucket implementation — containment, not throttling.
Graduated levels of trust assigned to AI agents: low trust requires explicit consent for every tool, high trust auto-approves common patterns. Capped by the user's RBAC permissions.
User-facing interface where a human explicitly authorizes an AI agent to access specific tools within defined boundaries. Time-boxed, revocable, and access-aware.
Technique that identifies and monitors AI agents by behavioral signature. Detects identity changes, tool usage pattern shifts, and privilege drift before they become incidents.
Property of an authorization system where decisions cannot be denied after the fact. Cryptographic receipts provide verifiable proof that a specific decision was made at a specific time.