Key Concepts

This page defines the core terms used throughout the ARX platform and documentation. Understanding these concepts is essential for configuring policies, deploying agents, and interpreting audit data.

Agent

An autonomous or semi-autonomous software program that performs security operations by interacting with tools through the ARX governance layer. Each agent is registered in the ARX Agent Registry with a unique identity (UUID), an owner, a set of permission bindings, and a declared intent manifest. Agents authenticate to ARX using an API key and execute operations through the SDK or REST API. ARX does not run agent code -- it governs the actions agents take.

Connector

A server-side component that maps abstract operation identifiers to specific API endpoints on a security tool. Each connector encapsulates the authentication method (OAuth2, API key, SAML), endpoint URLs, request formatting, and response normalization for one tool. For example, the CrowdStrike connector maps detections:read to GET /detects/queries/detects/v1 on the Falcon API. ARX ships with 101 connectors covering endpoint, SIEM, identity, cloud security, ticketing, and other tool categories.

Operation

A discrete action that an agent can perform through a connector. Operations are identified by a namespaced string in the format resource:action (e.g., detections:read, hosts:write, rtr:command_admin). Each operation has a defined HTTP method, API path, required scope, risk classification, and description. Operations are the unit of governance -- policy rules match on operation identifiers to determine whether an action is permitted, escalated, or denied.

Policy Rule

A configuration object that defines how the policy engine should evaluate a specific category of agent action. Each rule specifies match criteria (connector, operation pattern, agent identity, risk level, time-of-day, or custom attributes) and a verdict to return when the criteria match. Rules have a numeric priority. The policy engine evaluates rules in priority order and returns the verdict from the first matching rule. If no rule matches, the organization's default verdict applies.

Policy Verdict

The outcome of a policy evaluation for an agent action. There are exactly three possible verdicts:

Risk Score

An integer value computed by the policy engine for each operation attempt. The risk score incorporates the operation's static risk classification (low, medium, high, critical), the agent's behavioral history (session context), drift from declared intent, and organizational risk modifiers. Policy rules can match on risk score thresholds to apply different verdicts at different risk levels. For example, an organization might permit low-risk read operations automatically but escalate any operation with a risk score above 75.

Permission Binding

An association between an agent and a set of connectors and operations that the agent is authorized to use. Permission bindings are configured in the Agent Registry and define the maximum scope of actions an agent can attempt. The policy engine references permission bindings during evaluation. An agent that attempts an operation outside its permission bindings receives a DENY verdict regardless of other policy rules.

Intent Manifest

A declarative specification of the behavior an agent is expected to exhibit during normal operation. The intent manifest lists the connectors, operations, and parameter patterns that the agent is designed to use. It serves as a behavioral contract. ARX compares the agent's actual actions against its intent manifest to detect drift. Intent manifests are authored by the agent developer and reviewed by security teams before the agent is approved for deployment.

Declared Intent

The set of actions described in an agent's intent manifest. Declared intent represents the expected behavioral boundary for the agent. Any action that falls within declared intent is considered normal. Actions outside declared intent are flagged as behavioral drift and may trigger elevated risk scores or different policy verdicts.

Behavioral Drift

A condition in which an agent's actual behavior deviates from its declared intent manifest. Behavioral drift occurs when an agent attempts operations, connectors, or parameter patterns that are not listed in its manifest. ARX detects drift by comparing the current operation against the manifest at policy evaluation time. Drift can be caused by prompt injection, model hallucination, configuration errors, or legitimate changes in agent behavior that have not been reflected in the manifest. Drift events are recorded in the audit trail and can be configured to trigger ESCALATE or DENY verdicts.

Compliance Package

A generated set of compliance documentation derived from actual platform configuration and agent behavior. Compliance packages include Vendor Security Questionnaire (VSQ) responses, Data Flow Diagrams (DFDs), sub-processor lists, and SOC 2 control mappings. ARX generates these artifacts from live system data rather than static templates, ensuring that documentation reflects the current state of the deployment. Compliance packages can be regenerated on demand as the environment changes.

Audit Event

An immutable record of an agent action and its governance outcome. Every operation that passes through the ARX governance layer -- regardless of verdict -- produces an audit event. Each event captures the agent identity, organization, connector, operation, parameters, policy verdict, risk score, matched policy rule, timestamp, and execution result (for permitted operations). Audit events are stored in an append-only table. They cannot be modified or deleted. Events can be streamed to external SIEMs for correlation and long-term retention.

Organization (Org)

A tenant boundary within the ARX platform. All resources -- agents, connectors, policies, audit events, users, and secrets -- are scoped to an organization. Row-Level Security at the database layer enforces that data from one organization is never accessible to another. Each organization has its own policy rules, connector configurations, and user roster. Users belong to exactly one organization.

RBAC Roles

ARX enforces Role-Based Access Control on every API endpoint. Four roles are defined:

Every API request is checked against the authenticated user's role before the request is processed. Insufficient permissions result in a 403 Forbidden response.

Secrets Vault

The encrypted credential storage system within ARX. The secrets vault holds API keys, OAuth2 client ID/secret pairs, service account tokens, and other authentication material required by connectors. Credentials are encrypted at rest using organization-specific encryption keys. At operation execution time, the governance layer decrypts credentials and passes them to the connector. Credentials are never exposed to agent code, API responses, or audit logs. Organizations can bring their own encryption key material via AWS KMS, Azure Key Vault, or GCP KMS.

Connector Config

The stored configuration for a specific connector within an organization. A connector config includes the connector type (e.g., crowdstrike), a display name, the target environment details (API base URL, cloud region), a reference to the encrypted credentials in the secrets vault, and any connector-specific settings. Multiple connector configs can exist for the same connector type (e.g., separate CrowdStrike tenants for production and staging). Agents reference connector configs by the connector name when executing operations.

Approval Request

A pending human-in-the-loop review item created when an operation receives an ESCALATE verdict. An approval request captures the agent identity, connector, operation, parameters, risk score, and the policy rule that triggered the escalation. ARX sends the request as a structured notification to configured Slack channels or Microsoft Teams channels, including the full context and approve/deny action buttons. Reviewers can approve or deny the request from the notification or from the ARX console. The decision, the reviewer's identity, and the decision timestamp are recorded in the audit trail. If approved, the original operation is executed. If denied, the agent receives an ApprovalDeniedError.