Arximus is engineered to remain controlled even when components fail or are compromised. Separated authority, isolated security domains and controlled release prevent a single compromise from becoming unrestricted access, execution or control.
A compromised AI is still subject to the same authority, policy and release controls. It cannot grant itself additional authority or make an unauthorized consequential operation valid simply by requesting it.
Arximus authority controls do not depend on first detecting that the AI has been compromised. The same authority and release requirements apply to every protected operation, whether the AI is compromised or not.
Hostile context, poisoned inputs, manipulated tools or model error changes the AI's behavior and causes it to act outside its intended role.
The compromised AI proposes an action, resource, destination or protected parameters that exceed the authority originally granted to it.
The request still passes through trusted identity, delegated authority, the exact operation, current state, required external facts and deterministic policy.
Because the required authority or conditions are missing, Arximus denies, restricts or holds the operation instead of releasing it for execution.
Arximus separates security responsibilities and customer boundaries so compromise of one component, privilege domain or tenant does not automatically unlock the rest of the platform. Configuration, authorization, protected release, extensions, evidence and customer execution remain separated, while tenant-scoped security objects remain bound to trusted customer context.
Policies, credentials, connectors, actions, verification sources, extensions, evidence, usage and runtime state remain scoped to authenticated tenant, project and environment context. Access requires trusted tenant identity and explicit application-level authorization.
Admission controls, connection limits, bounded queues, compute isolation, load shedding and backpressure constrain resource consumption so overload or abuse in one tenant or workload cannot automatically become platform-wide impact.
The customer defines authority. The AI can request actions, but it cannot redefine the authority and policy Arximus enforces over those actions. AI-generated claims can inform a decision, but they cannot establish trusted identity, authority or classification on their own. Arximus separates asserted information from security context backed by configured trusted mechanisms.
Configuration changes have no effect on runtime authorization until a trusted version is deliberately published and activated. Runtime configuration is immutable and signed, while activation authority moves forward independently. A previously valid configuration cannot simply be replayed as current production authority.
Create policy against typed security context and compile it into a trusted runtime representation before it becomes eligible for activation.
Test new policy against representative or historical security context to see what it would allow, deny, restrict or hold before it can affect production.
Run new policy in non-enforcing shadow mode to observe the decisions it would produce under live runtime context, then complete any required review or approval before production activation.
Runtime accepts only trusted activation state that moves forward. Returning to older policy content requires a new authorized activation rather than replaying old authority.
Source control, build infrastructure, production admission and recovery systems are part of the Arximus security boundary. Changing source code is separated from the authority to place that code into production, while recovery remains protected from routine production administration.
Protected repositories, restricted maintainers, protected branches and mandatory review constrain who can change trusted Arximus source and release workflows.
Build environments are isolated from long-lived production authority, while dependency controls, security scanning, artifact integrity and build provenance protect the path from source to release artifact.
Production deployment is restricted to approved and trusted artifacts from the authorized build path. Manual replacement of runtime files does not become an alternate production release mechanism.
Backups use separate protection, restricted deletion and independent access controls so compromise of normal production administration does not automatically provide authority to destroy both production and recovery data.
Customers can add organization-specific security logic and route consequential operations through Arximus without making that code part of trusted Arximus infrastructure. Private Security Extensions run only inside isolated sandboxes. Customer business operations never run inside Arximus, whether they are submitted by the AI or released from a Protected Execution Function held by Arximus.
A private extension receives structured security context and only explicitly granted capabilities. Its authority exists only for the Event that invoked it, and it must terminate before that Event completes Protected Release. It can return facts, classifications, transformations, enrichment or workflow results without becoming authorization or release authority.
Customers can submit an operation their AI or application already possesses, or use a Protected Execution Function that Arximus stores and versions for stronger separation. In both modes, Arximus authorizes and binds the exact operation before controlled release to the customer-controlled executor. With a Protected Execution Function, the requesting AI does not need to possess the protected function at all.
Arximus protects the release path against changed parameters, changed destinations, conflicting Intent, stale authority and replay. Only the exact operation that passed authorization can become the operation Arximus releases.
Action, resource, destination and protected values remain part of the authorization itself instead of becoming reusable permission.
Current release authority, operation binding and applicable security state are verified again before protected material can leave Arximus.
Successful release consumes the matching single-use authority as part of the same protected transition, preventing the same authorization from silently producing another release.
RELEASED means Arximus made the exact authorized material available through the protected release interface. The customer-controlled system decides what happens after that boundary.
Security-critical failure is never treated as permission. Failure behavior is explicit for each workload and action class. Missing policy, required verification, release authentication or other mandatory security dependencies cannot become an implicit allow. Critical paths hold or fail closed, while lower-risk paths follow explicitly configured failure behavior.
Arximus preserves authorization and release history as immutable, causally linked Evidence. Distributed Evidence is committed into cryptographically protected checkpoints so historical security facts remain independently verifiable without forcing unrelated operations into one global chain.
Evidence records carry explicit causal relationships so authorization, verification, HOLD and release can be reconstructed without inventing a global order between unrelated operations.
Runtime components can create security Evidence without gaining ordinary authority to edit the historical records they already produced.
Evidence is committed into protected checkpoint generations that allow historical membership and integrity to be independently verified.
Higher-assurance deployments can anchor protected checkpoint material outside the normal Evidence path for additional independent verification.
Arximus does not depend on identifying every attack in advance. Compromised AI, customer code, administrative access and individual platform components remain subject to enforced authority, isolation and release boundaries. Compromise of one part cannot automatically provide unrestricted authority over the rest.
Compromise does not change the authority attached to an operation. Trusted identity, delegated authority, resource, destination, protected parameters, runtime state and deterministic policy still govern what can be authorized and released.
Identity and delegated authority originate from configured trusted mechanisms, not AI or client assertions. Claiming a role, principal or privilege cannot establish it.
Protected Release binds authority to the exact operation, protected parameters and approved destination. Changing a protected value invalidates the earlier decision. Intent integrity prevents a logical operation from silently becoming multiple releases, while single-use release authority rejects replay after consumption.
When Arximus Lock is enabled, the customer executor, gateway, network or protected system enforces the trusted Arximus release path and rejects protected operations that attempt to bypass it. Execution authority remains unavailable to the AI.
Private Security Extensions run behind a hardened isolation boundary with narrowly granted capabilities and no implicit access to privileged Arximus infrastructure. Customer business operations, whether submitted through Arximus or stored as Protected Execution Functions, are never executed inside Arximus.
Control Plane compromise cannot directly rewrite live runtime authorization. Runtime configuration is immutable and signed, and current activation authority advances independently so an attacker cannot turn an old valid configuration back into current production authority simply by replaying it.
Security Evidence is separated from ordinary content and preserved as immutable, causally linked records. Cryptographic checkpoint commitments protect large distributed Evidence sets without forcing unrelated operations into one fragile global chain.
Internal workloads receive narrow identities, permissions, network access and cryptographic roles. Cryptographic authority is separated by purpose, so compromising one service, key or signing role does not automatically grant the authority of another security domain.
Security ownership follows one canonical Tenant, Project and Environment hierarchy derived from trusted context. Conflicting scope cannot be repaired or accepted as an alternate interpretation, and security objects remain bound to the scope that actually owns them.
Privileged production authority is separated from normal employee access and constrained through stronger authentication, action-scoped administrative authority, independent privilege domains and audit. A separately protected emergency authority remains available to stop critical release outside the normal Control Plane.
Source changes, build authority and production admission remain separate control points. Protected repositories, mandatory review, isolated builds, trusted artifacts and controlled deployment prevent ordinary development access from silently becoming unrestricted production replacement authority.
Recovery data remains protected through encryption, isolation, restricted deletion and independent access controls so compromise of normal production administration does not automatically provide authority over every backup.
Arximus constrains what compromised AI, customer code, tenants, administrative identities and individual platform components can reach next. Trusted authority, tenant isolation, separated privileges, controlled production change, protected execution, explicit failure behavior and integrity-protected evidence keep compromise from automatically becoming unrestricted control.
