Glossary
Permission and Scope Management
Permission and Scope Management
Terms related to the systems that define and enforce what tools, data, and actions an AI agent is authorized to access based on identity and context. Target: Security Architects and Product Managers.
Access Control List (ACL)
An Access Control List (ACL) is a security mechanism that enumerates which users or system processes are granted access to specific objects, such as files, directories, or network resources, along with the operations they are permitted to perform.
Attribute-Based Access Control (ABAC)
Attribute-Based Access Control (ABAC) is an authorization model that grants or denies access to resources based on a set of attributes associated with the user, the resource, the action, and the environment, evaluated against a defined policy.
Audit Trail
An audit trail is a chronological, immutable record of security-relevant events and actions, such as authentication attempts, data access, and configuration changes, used for forensic analysis, compliance, and detecting anomalous behavior.
Authorization Boundary
An authorization boundary is the logical perimeter that defines the scope of resources, data, and operations for which a specific set of permissions or a security principal is valid.
Capability-Based Security
Capability-based security is a model where access rights are represented as unforgeable tokens (capabilities) that a process must possess to interact with a resource, combining the designation of the object and the authority to access it in a single entity.
Claim
In security, a claim is a statement about a subject (such as a user or service) asserted by an identity provider, containing attributes like name, role, or group membership, which is used in token-based authorization decisions.
Context-Aware Authorization
Context-aware authorization is a dynamic access control approach where authorization decisions are based not only on identity and permissions but also on real-time contextual factors such as location, time, device security posture, and behavioral patterns.
Credential Scoping
Credential scoping is the practice of limiting the permissions and resource access granted to a set of security credentials (like an API key or OAuth token) to the minimum necessary for their intended function, adhering to the principle of least privilege.
Discretionary Access Control (DAC)
Discretionary Access Control (DAC) is an access control model where the owner of a resource determines who can access it and what permissions they have, typically implemented using access control lists (ACLs).
Entitlement
An entitlement is a defined right or permission granted to a user or system identity to perform a specific operation on a particular resource within a computing environment.
Fine-Grained Permissions
Fine-grained permissions are a detailed set of access controls that specify precise, low-level actions (e.g., 'read:document', 'write:field') on specific resources, as opposed to broad, all-or-nothing roles.
Identity Provider (IdP)
An Identity Provider (IdP) is a system entity that creates, maintains, and manages digital identity information for principals (users or services) and provides authentication services to relying applications within a federated identity model.
Just-in-Time (JIT) Access
Just-in-Time (JIT) access is a security practice where elevated permissions are granted to a user or system for a specific, limited timeframe only when explicitly requested and approved, rather than being permanently assigned.
Least Privilege Principle
The principle of least privilege is a core security concept that mandates every user, process, or system should have the minimum levels of access—or permissions—necessary to perform its legitimate functions.
Mandatory Access Control (MAC)
Mandatory Access Control (MAC) is a non-discretionary security model where access decisions are made by a central authority based on predefined security labels (e.g., classifications, compartments) assigned to both subjects and objects.
OAuth 2.0 Scopes
OAuth 2.0 scopes are strings that specify the precise permissions a client application is requesting when asking for an access token, limiting the token's authority to a defined subset of the resource owner's access rights.
Open Policy Agent (OPA)
Open Policy Agent (OPA) is an open-source, general-purpose policy engine that unifies policy enforcement across the stack by decoupling policy decision-making from application logic using a declarative language called Rego.
Permission Boundary
A permission boundary is an IAM management feature that sets the maximum permissions an IAM entity (user or role) can have, preventing privilege escalation even if broader policies are attached directly to the entity.
Policy Decision Point (PDP)
A Policy Decision Point (PDP) is the system component in a policy-based architecture that evaluates access requests against applicable policies and rules to render an authorization decision (allow or deny).
Policy Enforcement Point (PEP)
A Policy Enforcement Point (PEP) is the system component that intercepts access requests, consults a Policy Decision Point (PDP) for an authorization decision, and enforces that decision by permitting or denying the request.
Policy-as-Code
Policy-as-Code is the practice of defining and managing security, compliance, and operational policies using machine-readable definition files, which can be version-controlled, tested, and automated like software code.
Privileged Access Management (PAM)
Privileged Access Management (PAM) encompasses the cybersecurity strategies and technologies used to control, monitor, and secure access to highly sensitive accounts, credentials, and systems that provide elevated permissions.
Resource-Based Policy
A resource-based policy is an access control policy that is attached directly to a resource (e.g., an S3 bucket, a Lambda function) and specifies which principals are allowed to perform which actions on that resource.
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) is an access control model where permissions are assigned to roles, and users are assigned to appropriate roles, thereby simplifying permission management in large organizations.
Security Assertion Markup Language (SAML)
Security Assertion Markup Language (SAML) is an open XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP) to enable web-based single sign-on (SSO).
Security Token
A security token is a digitally signed data object, such as a JSON Web Token (JWT) or SAML assertion, that contains claims about a subject and is used to prove authentication and convey authorization grants in a stateless manner.
Service Account Permissions
Service account permissions are the access rights and roles assigned to a non-human identity (a service account) used by an application, daemon, or automated process to authenticate and interact with other services and resources.
Tenant Isolation
Tenant isolation is a security and architectural principle in multi-tenant systems that ensures the data, configuration, and runtime of one tenant (customer or user group) are logically or physically separated and inaccessible to other tenants.
Token Scope
Token scope refers to the specific set of permissions and resource access limitations encoded within or associated with an access token, as defined during the authorization grant process (e.g., via OAuth 2.0 scopes).
Zero-Trust Network Access (ZTNA)
Zero-Trust Network Access (ZTNA) is a security framework that provides secure remote access to applications and services based on strict identity verification and context-aware policies, without assuming trust based on network location.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us