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.
Per-key and per-tenant limits, request and token-volume controls, connection limits, load shedding and backpressure constrain resource consumption so overload or abuse in one area does not 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 new policy version is deliberately published and activated. Policy is versioned, signed and delivered as immutable runtime configuration. The Runtime verifies the version before activation, while the existing trusted policy remains in force until replacement.
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.
Publish an immutable version, verify it inside the runtime and retain rollback to a previous known-good policy when required.
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. It can return facts, classifications, transformations, enrichment or workflow results, but it cannot become the authorization authority or gain implicit access to Arximus infrastructure, other tenants or customer execution 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.
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 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 authorization to the exact operation, protected parameters and approved destination. Changing a protected value invalidates the previous authorization, while short-lived single-use Release Grants reject 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. Policy is versioned, signed and published as immutable runtime configuration, and the Runtime verifies the trusted version before activation.
Security evidence is separated from ordinary content and written to append-only or equivalent integrity-protected storage. Cryptographic hash chaining and signed checkpoints protect the recorded history of authorization, release and reported execution results.
Internal workloads receive narrow identities, permissions, network access and cryptographic roles. Compromising one service does not automatically grant the privileges, secrets or authority of another security domain.
Tenant identity comes from authenticated trusted context. Policies, credentials, connectors, verification sources, extensions, evidence, usage and runtime state remain tenant-scoped and require explicit authorization before access.
Privileged production authority is separated from normal employee access and constrained through stronger authentication, scoped temporary elevation, 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.
