ARXIMUS AI Runtime Authorization
Request a Demo

ARXIMUS
AI Runtime Authorization Engine

Enforcement infrastructure for AI security and governance.

The authorization and enforcement layer between AI and the systems it can act on. Arximus determines whether protected actions are authorized, enforces those decisions at runtime and preserves evidence of what happened.


IDENTITY → CONTEXT → AUTHORITY → POLICY → EXECUTION → EVIDENCE
Request access Explore security
AUTHORITY IDENTITY POLICY VERIFICATION BINDING EXECUTION LOCK EVIDENCE
AI AUTHORITY CONTROL

Control AI authority before it becomes action.

Arximus intercepts AI actions at runtime, before execution, giving you direct control over what AI can access, change, send and run.

Each protected action is evaluated against identity, delegated authority, policy, data sensitivity, provenance, risk, transaction context and, when required, authoritative external facts. Arximus can allow, deny, restrict, redact, transform, hold or require approval before a protected operation is released.

CENTRALIZED ENFORCEMENT

One security layer controls AI authority across the protected execution path.

Arximus centralizes critical security decisions across AI systems, identity, tools, data, credentials, policy and execution.

Arximus brings identity, delegated authority, data, tools, resources, transactions, provenance, risk and execution state into one coordinated authorization path. Deterministic policy decides what may proceed, while External Verification confirms authoritative facts when required. For consequential systems, Protected Execution separates AI intent from downstream execution authority, binds authorization to the exact operation and approved destination, and controls what reaches customer-controlled execution. Authorization, release and reported execution results are preserved as integrity-protected security evidence.

AUTHORITY

Trusted Authority

Resolve trusted principal, agent and delegated authority before consequential actions proceed.

POLICY

Deterministic Policy

Enforce explicit security and business rules outside the AI system being governed.

VERIFY

External Verification

Confirm approvals, entitlements and other facts against customer-approved authoritative systems.

CREDENTIALS

Credential Isolation

Keep reusable downstream credentials outside the AI path for selected protected integrations.

BIND

Transaction Binding

Bind authorization to the exact action, destination and protected parameters that were approved.

EXECUTE

Protected Execution

Authorize and bind exact protected operations, then control what reaches customer-controlled execution.

REPLAY

Replay Resistance

Reject altered or replayed execution through short-lived, operation-bound authorization.

EVIDENCE

Verifiable Evidence

Preserve structured, integrity-protected evidence of authorization decisions and execution results.

DEPLOYMENT

Connect Arximus without rebuilding your stack.

Provider neutral by design.

Use the AI provider, model or compatible API endpoint you already operate. Arximus is 100% provider neutral and adds the runtime security path without tying your application to a specific provider, model or infrastructure stack.

Keep your applications, agents, models, tools, APIs, data and infrastructure in place. Route the AI activity you want to secure through Arximus, then expand control from the same security path as your requirements grow.

APPLICATION · PROVIDER · INFRASTRUCTURE REMAIN IN PLACE
CONNECT IN MINUTES

Change the route, not the application.

Connect the AI provider or compatible API endpoint you already use, point your existing application traffic to Arximus and route it through the runtime security path.

  1. 01
    Configure the provider

    Add the AI provider or compatible endpoint and its provider credential to the Arximus environment.

  2. 02
    Point traffic to Arximus

    Change the application's AI base URL to the Arximus runtime endpoint.

  3. 03
    Use the environment key

    Replace the provider-facing application credential with the environment-specific Arximus credential.

  4. 04
    Route normally

    Existing AI traffic now crosses the Arximus security path before continuing to the same provider.

PROGRESSIVE CONTROL

Start with the connection. Add deeper control as requirements increase.

Start with the standard Arximus security path, then add deeper controls without rebuilding the systems you already operate.

Add organization-specific security logic, authoritative external verification and stronger execution controls progressively as the risk, consequence and requirements of each protected operation increase.

01 / CONNECT FAST START

Connect what you already run

Route existing AI applications and agents through Arximus while your models, tools, APIs, data and infrastructure remain where they already operate.

  • Existing applications & agents
  • Provider-neutral
  • Existing systems stay in place
  • Progressive deployment
02 / ADAPT PRIVATE LOGIC

Make Arximus understand your organization

Add your own identity model, authority rules, classifications, detections, business objects, integrations and private extensions without changing the Arximus core.

  • Private extensions
  • Custom security facts
  • Organization-specific context
  • Custom integrations & workflows
03 / VERIFY AUTHORITATIVE FACTS

Authorize against authoritative external facts

Add External Verification when authorization depends on approvals, entitlements, limits or other authoritative facts held in customer-approved systems.

  • Deterministic policy
  • External Verification
  • Approvals & entitlements
  • Customer-approved data sources
04 / ENFORCE PROTECTED PATH

Add deeper control where consequences increase

For higher-consequence operations, add Protected Execution, credential isolation, exact operation binding and Arximus Lock wherever stronger enforcement is required.

  • Credential isolation
  • Exact operation binding
  • Protected Execution
  • Arximus Lock
CUSTOM AUTHORITY & LOGIC

Define authority in the terms your organization already uses.

Arximus does not impose a fixed business vocabulary or authority model. Define the actions, resources, business objects, identifiers, relationships, classifications and rules that matter in your environment. Private logic can calculate organization-specific facts and results, while deterministic Arximus policy remains the final authorization authority.

RULES

Define your own authority rules

Express organization-specific permissions, transaction limits, data restrictions, approval requirements, exceptions and business conditions using the security context available to Arximus.

Context → Rules → Authority → Decision
CODE

Build private security and business logic

Use private functions for organization-specific calculations, classifications, relationships, workflow state, risk signals and other logic that generic infrastructure cannot know. Private functions return structured facts and results. They do not independently authorize or release protected operations.

Custom Logic → Facts → Deterministic Policy
MODEL

Define your own authority vocabulary

Represent the actions, resources, business objects, identifiers and relationships that matter to your organization using your own vocabulary. Arximus maps them into runtime authority context without requiring changes to the authorization core.

Your Objects → Typed Context → Policy
DETECT

Build security detections unique to you

Add custom detection logic for organization-specific threats, suspicious conditions, prohibited combinations, business risk signals and other patterns that generic controls cannot know.

Signals → Detection → Security Facts
INTEGRATE

Build private integrations

Connect organization-specific services, proprietary systems and internal workflows through explicitly permitted capabilities so custom security logic can exchange the context and results it requires.

Private Systems → Context → Functions → Results
TRANSFORM

Change data before it moves

Build private transformations, redaction logic, parsers and enrichment functions that can modify or enrich information before it is used by downstream security decisions or released through protected paths.

Parse → Enrich → Redact → Transform
WORKFLOW

Build security into your workflows

Create organization-specific workflows for approvals, escalation, enrichment, verification and other security processes without modifying the trusted Arximus core.

Trigger → Workflow → Result → Policy
ISOLATE

Customize without weakening the boundary

Customer extensions execute outside the trusted runtime with structured inputs and explicitly granted capabilities. They can return facts, classifications, transformations and workflow results, but deterministic Arximus policy remains the final authorization authority.

Private Code → Isolation → Facts → Policy
RUNTIME AUTHORIZATION

Define AI authority precisely and enforce it before execution.

Arximus applies AI Runtime Authorization to each protected action proposed by an AI application or agent. It turns the exact operation into a deterministic authorization decision, evaluating authority, action type, resource, destination, protected parameters, transaction limits and business rules together with customer-specific context, relevant prior state and authoritative external facts when required. For selected operations, Arximus can bind that authorization to the exact transaction, carry it into protected execution and preserve evidence of the decision and result.

PROPOSED OPERATION Execute treasury payment
ACTION payment.execute
AMOUNT USD 185,000
BENEFICIARY Vendor 8842
SOURCE ACCOUNT Account 7719
TRANSACTION ID PAY-5683456
01

Authorized to execute payments?

REQUIRED
02

Authorized for payment.execute?

REQUIRED
03

USD 185,000 within delegated limit?

REQUIRED
04

Vendor 8842 within permitted beneficiary scope?

REQUIRED
05

Account 7719 authorized for this operation?

REQUIRED
06

Data, classifications and relevant prior state satisfy policy?

REQUIRED
07

Authoritative approval exists for this exact transaction?

VERIFY
08

Approval matches amount, beneficiary and account?

VERIFY
ARXIMUS AUTHORIZATION Every required condition must match the exact operation.

If policy requirements and authoritative verification are satisfied, Arximus binds authorization to the action, amount, currency, beneficiary, source account and transaction ID. For protected execution, a short-lived single-use Release Grant carries that exact authorization through the Protected Release Plane, which releases only the matching operation to the approved customer-controlled executor. Changed protected values or replayed use of the grant are rejected, and security evidence preserves authorization, release and the execution result when it is authoritatively reported by the customer-controlled system.

01 / NORMALIZE

Understand the exact operation

Convert protected AI activity into one normalized security context containing the application, agent, model, tool, action, resource, destination, parameters, transaction fields and other relevant runtime context.

AI Activity → Typed Operation → Security Context
02 / AUTHORITY

Verify authority for the exact action

Determine whether the AI is authorized to perform the proposed operation under its exact conditions, including the action type, capability, resource, destination, transaction value, protected parameters and other customer-defined limits.

Action → Scope → Conditions → Authority
03 / POLICY

Apply policy specific to the operation

Run deterministic requirements for the exact action, tool, resource, destination, environment, transaction value, protected parameters, approvals and other conditions your organization defines.

Action → Conditions → Policy → Decision
04 / BUSINESS LOGIC

Apply your organization’s own meaning

Use private functions, classifications, business facts, integrations and workflows to define security meaning and requirements that are unique to your organization.

Custom Logic → Facts → Context → Policy
05 / DATA + STATE

Decide with relevant context and history

Carry forward relevant classifications, provenance, resources accessed, previous actions and execution history so the current authorization decision can account for what already happened.

Previous Activity → State → Current Action
06 / VERIFY

Check authoritative facts when required

When policy depends on information held elsewhere, retrieve approvals, entitlements, limits or other required facts from configured customer-approved authoritative systems before completing authorization.

Policy → Required Fact → Verification → Decision
07 / BIND

Bind authorization to the exact transaction

Bind the authorization to the approved action, resource, destination and protected transaction values so changed amounts, beneficiaries, accounts or other protected parameters cannot inherit the previous decision.

Decision → Exact Values → Bound Authorization
08 / ENFORCE

Control what happens next

Apply the exact policy outcome before execution. Arximus can allow, deny, restrict, redact, transform, hold, flag or require approval according to the operation and conditions being evaluated.

Decision → Control → Release or Refuse
09 / EXECUTE

Control what reaches execution

For selected operations, Protected Execution uses short-lived single-use Release Grants bound to the exact authorized operation and approved destination. Changed or replayed attempts are rejected, and only the matching operation reaches customer-controlled execution.

Authorize → Bind → Grant → Execute
EXTERNAL VERIFICATION

Verify critical actions against external authoritative systems at runtime.

An action can satisfy every authority and policy rule inside Arximus and still fail authorization if the external system your organization trusts does not confirm it.

External Verification is an optional higher-assurance control that lets you configure Arximus to check required facts against customer-approved external databases, APIs, approval systems and other authoritative sources at runtime, while the authorization decision is being made. Arximus retrieves the required facts, matches them to the exact proposed operation and applies deterministic policy before execution is released.

Approval databases Internal APIs Entitlement systems Risk systems Payment records Change records Authorization systems Customer data sources
RUNTIME EXTERNAL VERIFICATION
01
ARXIMUS AUTHORITY + POLICY Internal authorization checks pass

Payment authority, transaction limit, beneficiary scope, source account and other configured policy requirements are satisfied.

02
EXTERNAL VERIFICATION REQUIRED Policy requires authoritative confirmation

Before PAY-5683456 can proceed, customer policy requires its approval status to be confirmed outside Arximus.

03 RUNTIME EXTERNAL VERIFICATION

Check payment approval system now

While authorization is in progress, Arximus queries the configured external customer controlled database, API or approval system for transaction PAY-5683456.

ARXIMUS → EXTERNAL SOURCE → CURRENT FACT
04
AUTHORITATIVE RESULT PAY-5683456 / PENDING

The external customer-controlled system confirms that the transaction exists, but its current approval status is still pending.

05
EXACT TRANSACTION VERIFICATION Amount + beneficiary + account must match

Arximus can require the returned record to match the exact transaction ID, amount, beneficiary, source account and other protected fields before verification is satisfied.

ARXIMUS POLICY DECISION HOLD

Internal authority and policy passed, but the external authoritative source has not approved the transaction. The USD 185,000 payment is not released.

PROTECTED EXECUTION

Control exactly what reaches execution, and under what authority.

Arximus supports two protected execution modes. A customer can store and version a Protected Execution Function in Arximus and let the AI request it by ID, or an AI application can submit an exact operation it already constructs. In both modes, Arximus authorizes and binds the exact operation, protected parameters and approved destination before it can reach customer-controlled execution. Arximus does not perform the customer business action.

A
PROTECTED FUNCTION

AI requests a Protected Execution Function

The customer stores and versions a Protected Execution Function in Arximus. The AI requests it by its defined ID and supplies the required parameters, but does not need to possess the protected function itself.

OR
B
SUBMITTED OPERATION

AI submits an operation it already constructs

The AI application constructs or already possesses the proposed operation and sends the exact action through Arximus. Security-relevant fields are normalized into the typed operation that is evaluated, bound and controlled before it can reach execution.

SHARED PROTECTED EXECUTION MODEL
TWO MODES

Protect execution without forcing one integration model

Use Protected Execution Functions for capabilities the AI should only request, while existing AI applications continue submitting operations they already construct. Both modes place execution behind the same authority and exact-operation controls.

CUSTOMER DEFINED

Define exactly what may reach execution

Protected Execution Functions can have their own ID, class, inputs, destination, authority requirements and policy conditions so customers define precisely when and where each protected function can proceed into customer-controlled execution.

BINDING

Authorization follows the exact operation

Arximus binds authorization to the exact function or submitted operation, resource, destination and protected parameters that passed policy. Changing a protected value requires a new authorization decision.

EXECUTION

Arximus controls the path. Customer systems execute.

Arximus refuses unauthorized operations or releases the exact authorized operation to the approved customer-controlled executor. Customer infrastructure retains the credentials and execution authority required to perform the business action.

ARXIMUS LOCK

Bypassing Arximus invalidates the operation.

Arximus Lock is the enforcement layer that extends Arximus authorization into the customer-controlled execution environment. It makes valid Arximus authorization a requirement for protected operations to proceed, so customer-controlled gateways, networks, executors or protected systems can distinguish an authorized release from a direct or bypassed request.

DIRECT PATH REJECTED
AI / AGENT
→
DIRECT OPERATION
→
CUSTOMER SYSTEM

The AI attempts to send the protected operation directly to the customer system, bypassing Arximus. Because the request does not carry the valid Arximus authorization and controlled release required by the customer’s Lock configuration, the customer-controlled enforcement point rejects it. The bypassed operation does not enter the protected execution path.

AUTHORIZED PATH ACCEPTED
AI / AGENT
→
ARXIMUS
→
AUTHORIZED RELEASE
→
CUSTOMER EXECUTOR

Arximus authorizes and binds the exact operation, then releases it to the approved customer-controlled executor with the required authorization proof. The customer-controlled enforcement point validates that release and permits only the matching authorized operation to continue. The operation is accepted onto the protected execution path, while actual execution remains under customer-controlled authority.

AUTHORIZATION

Require proof of Arximus authorization

The customer-controlled executor or gateway can require a valid Arximus authorization and release before accepting a protected operation, so an AI-generated request is not treated as authorized by itself.

GATEWAY

Enforce the requirement inside customer infrastructure

A customer-controlled API gateway, service or execution layer can validate the Arximus authorization before allowing the protected operation to reach its destination.

NETWORK

Remove the direct route

Customer network policy, private connectivity or service isolation can prevent the AI environment from reaching critical systems through an alternative path that bypasses Arximus.

CREDENTIALS

Keep execution credentials outside the AI path

Credentials required to perform protected operations can remain with the customer-controlled application or executor that accepts authorized Arximus releases, rather than being exposed to the AI environment.

RUNTIME SECURITY

Defend the context around every authorization decision.

Arximus applies deterministic inspection across protected traffic and gives customers the ability to add their own private runtime security functions when deeper or organization-specific analysis is required. Custom functions can return security facts and classifications, including results from customer-defined semantic analysis, while deterministic Arximus policy remains the authority that decides what may proceed.

DATA

DLP & deterministic detection

Detect configured secret formats, credential patterns, structured PII, customer rules, forbidden values, classifications, schema violations and parameter limits using predictable runtime checks that policy can act on.

SEMANTIC

Build your own semantic analysis

Customers can create private security functions for prompt injection, suspicious instructions, context manipulation, semantic exfiltration or other meaning-based analysis using the models, classifiers, algorithms or services they choose.

TOOLS

Control Tool & MCP activity

Inspect protected tool and MCP operations against action schemas, destinations, parameters and customer-defined rules, with optional private functions providing additional classifications or security facts where required.

MEMORY

Apply security to RAG & memory

Apply classifications, provenance, deterministic rules and optional customer-defined analysis to retrieved or stored context when those reads, writes or retrieved contexts pass through Arximus.

PROVENANCE

Carry security context forward

Preserve relevant provenance, classifications, resources accessed, previous actions and other security state so later authorization decisions can account for the context that influenced them.

CONTROL

Turn security facts into enforcement

Deterministic policy decides what detected facts, classifications and customer-defined analysis mean, then applies the configured outcome such as allow, deny, restrict, redact, transform, hold or require additional approval.

ARXIMUS SECURITY ARCHITECTURE

Built so one compromise does not become total compromise.

Arximus is designed under an assume-breach model. Security responsibilities are separated across independently constrained domains so compromise of a dashboard, runtime service, extension, credential role or other component does not automatically provide the authority of the entire platform.

CONTROL

Control Plane

Customers configure organizations, environments, integrations, policies, connectors, extensions, approvals and other settings without the Control Plane directly performing normal runtime enforcement.

RUNTIME

Runtime Data Plane

Processes protected AI activity, builds trusted runtime context and makes normal authorization decisions without possessing the customer execution credentials required to perform protected business actions.

DETECTION

Detection Plane

Performs deterministic runtime detection such as secret, credential, structured data, schema, classification and parameter checks, producing security facts that deterministic policy can use without detection becoming the authorization authority.

EXTENSIONS

Extension Plane

Runs customer-defined functions behind a hardened security boundary with structured inputs, explicit capabilities and restricted outputs, including optional customer-defined semantic analysis and other private detection logic.

RELEASE

Protected Release Plane

Verifies that a protected operation matches its authorization and releases only the exact approved function or submitted operation to the configured customer-controlled executor. It does not perform the customer action itself.

EVIDENCE

Evidence Plane

Receives structured security evidence through a dedicated integrity-protected path. Runtime components may append evidence but must not silently rewrite historical records.

SECRETS

Secrets & Cryptography

Provider credentials, release-channel credentials where required, signing keys, protected-function integrity and cryptographic roots are separated by role rather than concentrated behind one universal secret or key. Customer execution credentials remain customer-side.

INTERNAL TRUST

Explicit service authority

Internal workloads receive narrow identities, IAM permissions, network permissions and egress rules. Network location alone does not create trust.

Signed immutable runtime configuration Separate cryptographic roles Default-deny internal access Blast-radius reduction
EVIDENCE & RETENTION

Zero-retention content without losing accountability.

AI content, security evidence and metadata are separate data classes inside Arximus.

By default, ordinary AI input and output content is processed without being retained. Structured security evidence is preserved separately, allowing Arximus to record what was evaluated, which authority and policy applied, why a decision was made, what external facts or approvals were used, what exact operation was authorized and whether it was released.

Evidence can include identity references, action and parameter hashes, policy versions, decision reasons, verification results, approval references, release information and execution results when they are authoritatively reported back by a customer-controlled system. Arximus distinguishes authorization from release, and release from actual execution.

Customers that require content retention can enable full AI input and output logging under their configured retention controls, while policy-controlled forensic capture can preserve selected content when required for investigation or compliance.

Structured evidence can be written to append-only or equivalent integrity-protected storage with cryptographic hashes and signed checkpoints. Where stronger independent verifiability is required, checkpoint material can also be anchored outside the normal Arximus evidence system.

Zero-retention AI content by default Structured security evidence retained separately Optional full input & output logging Policy-controlled forensic capture Append-only integrity protection Cryptographic checkpoints
IDENTITY & AUTHORITY Who or what requested the operation principal / application / agent / delegation
POLICY & VERIFICATION Why the decision occurred policy version / reasons / approvals / verified facts
BINDING & RELEASE What Arximus authorized and released action hash / parameter hash / connector / release result
INTEGRITY Protected security evidence append-only storage / hashes / signed checkpoints
DEPLOYMENT OPTIONS

Choose the Arximus deployment model that fits your requirements.

Use Arximus Cloud or Arximus Enterprise depending on the infrastructure, connectivity, regional, data and service requirements of your environment.

In both deployment models, Arximus operates the security platform while your AI applications, models, tools, APIs and data remain in the environments you control.

  1. CLOUD
    Arximus Cloud

    Managed Cloud deployment for existing AI environments. Connect the AI systems you want to secure and begin routing protected activity through the Arximus Cloud security path.

  2. ENTERPRISE
    Arximus Enterprise

    Stronger deployment boundaries for critical AI environments, with dedicated environment options, private connectivity, regional requirements, retention and evidence controls, enterprise governance, contracted capacity and service requirements.

  3. INFRASTRUCTURE
    Dedicated Boundaries & Private Connectivity

    Enterprise agreements can define dedicated infrastructure options, single-tenant isolation, private encrypted connectivity and controlled ingress and egress where organizational requirements demand stronger separation.

  4. CONTROL
    Regional, Data & Service Requirements

    Define contracted requirements around regional deployment, data residency, retention, evidence, encryption, governance, capacity, support and operational service levels.

START USING ARXIMUS

Put AI authority under explicit control.

Start with the AI systems you already operate, then progressively add trusted identity, customer-defined authority, deterministic policy, External Verification, Protected Execution and Arximus Lock wherever deeper control is required.

Request access Explore security
ARXIMUS CONTROL MODEL
Protected AI actions remain inside explicit authority
  • Trusted identity and delegation establish who or what is authorized to act.
  • Deterministic policy evaluates the exact operation, resource, destination and protected parameters.
  • External Verification brings required authoritative facts into runtime authorization.
  • Exact operation binding prevents changed protected values from inheriting a previous authorization.
  • Protected Execution separates AI intent from the customer-controlled authority that performs the business action.
  • Arximus Lock makes bypassed protected operations invalid where customer infrastructure enforces the Arximus-authorized execution path.
  • Integrity-protected evidence distinguishes authorization, release and reported execution.
Enterprise requirements

Need private connectivity, dedicated environment options, regional requirements, custom retention and evidence controls, enterprise governance or contractual service requirements?

Explore Enterprise