Trusted Authority
Resolve trusted principal, application, agent and delegated authority before consequential actions can proceed.
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 → SCOPE → CONTEXT → AUTHORITY → POLICY → BINDING → RELEASE → EXECUTION → EVIDENCE
AUTHORITY
IDENTITY
POLICY
VERIFICATION
BINDING
EXECUTION
LOCK
EVIDENCE
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 current operational 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 machine intent from downstream execution authority, binds authorization to the exact operation and approved destination, and controls what Arximus is permitted to release. Authorization and release are preserved as integrity-protected Evidence, while actual execution remains under customer control.
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.
CUSTOMER CONTROLLED
AI APPLICATION
PROVIDER NEUTRAL
AI PROVIDER / ENDPOINT
ARXIMUS
RUNTIME SECURITY PATH
IDENTITY + CONTEXT
AUTHORITY + POLICY
RUNTIME CONTROLS
EVIDENCE
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.
-
01
Configure the provider
Add the AI provider or compatible endpoint and its provider credential to the Arximus environment.
-
02
Point traffic to Arximus
Change the application's AI base URL to the Arximus runtime endpoint.
-
03
Use the environment key
Replace the provider-facing application credential with the environment-specific Arximus credential.
-
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.
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.
Define your own authority rules
Express organization-specific permissions, transaction limits, data restrictions, authoritative approval conditions, exceptions and business requirements using the security context available to Arximus.
Context → Rules → Authority → Decision
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
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
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
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
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
Connect security to your workflows
Connect organization-specific escalation, enrichment, verification and customer-controlled approval systems without moving final authorization authority outside deterministic Arximus policy.
External State → Security Facts → Policy
Customize without weakening the boundary
Customer extensions execute outside the trusted runtime with structured inputs and explicitly granted capabilities. Their authority exists only for the Event that invoked them, and they can return facts, classifications, transformations and workflow results without becoming authorization or release authority.
Event → Isolated Logic → Facts → Policy
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 Plane
Customers configure organizations, environments, integrations, policies, connectors, extensions and security settings without giving the Control Plane direct runtime authorization or Protected Release authority.
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 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.
Extension Plane
Runs customer-defined logic behind a hardened security boundary with structured inputs and explicit capabilities. Extension authority remains bound to the Event that invoked it and cannot become independent authorization or release authority.
Protected Release Plane
Revalidates current release authority, verifies the exact operation and publishes only the matching authorized function or submitted operation. Successful publication consumes its single-use release authority so the same authorization cannot silently produce another release.
Evidence Plane
Preserves immutable, causally linked security Evidence through a dedicated integrity-protected path and cryptographically commits distributed Evidence into independently verifiable checkpoints.
Secrets & Cryptographic Authority
Cryptographic authority is separated by purpose so provider-secret protection, configuration authority, Evidence signing, release authority and workload identity cannot collapse into one universal cryptographic role. Customer execution credentials remain customer-side.
Explicit service authority
Internal workloads receive narrow identities, IAM permissions, network permissions and egress rules. Network location alone does not create trust.
Anti-rollback runtime configuration
Purpose-bound cryptographic authority
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.
-
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.
-
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.
-
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.
-
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.
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