TECHNICAL
Specifications

Human, application and machine actors

• Application identity. Applications are identified independently from their API credential material.
• Service identity. Service-to-service requests carry an explicit requesting principal.
• Agent identity. Agents are recognized as defined machine principals. Self-declared model attributes do not establish trusted authority.
• Automation identity. Automated workflows operate under explicit principal identity and delegated scope.
• Human-to-machine chains. Human authority delegated to applications, services and agents remains attributable to its originating authority.
• Actor-neutral enforcement. Identity, delegation and Policy boundaries apply consistently to agents, applications, services and automations.

Authority cannot expand downstream

• Authority narrowing. A child delegation cannot grant more than its parent possesses.
• Inherited constraints. Restrictions and scope boundaries remain effective through delegation.
• Operation specificity. Delegations can be constrained by permitted actions, resources and destinations.
• Chain validation. Effective authority depends on the entire relevant delegation chain.

Live delegation validity

• Decision-time validation. Consequential Policy decisions evaluate current principal and delegated authority, not only identity accepted at intake.
• Revocation propagation. Revoking upstream authority invalidates dependent delegated access.
• State-based validity. Authority changes and revocation are established by current authoritative state, not the passage of time alone.
• Scope compatibility. A delegation for one security scope does not authorize another.
• Grant-time revalidation. Creating new release authority requires applicable principal and delegation authority to remain current.
• Release-boundary validation. Protected Release rechecks actor authority when required by the applicable release contract.

Arximus context tokens

• Signed context. Runtime context tokens carry verifiable identity and authority claims.
• Token binding. Context is bound to its intended issuer, subject, purpose and scope.
• Trust separation. Customer assertions are not silently promoted to verified identity or authority.
• Claim verification. Token claims are checked before becoming inputs to Policy.

One logical operation, one Intent

• Intent identity. A logical customer operation has a persistent identity separate from transport retries.
• Event identity. An accepted Runtime Event has its own identity and causal history.
• Operation fingerprinting. Relevant security semantics are captured in a canonical operation fingerprint.
• Duplicate detection. Retries and repeated delivery cannot silently create a new authorized operation.

Retry, replay and ambiguity handling

• Idempotent intake. Repeated delivery is reconciled against authoritative Intent state.
• Conflicting duplicates. Identical identifiers with inconsistent operation content produce an integrity conflict.
• Ambiguous retries. Unclear equivalence cannot be treated as an independent safe request.
• Crash-safe acceptance. Intake records are committed durably before consequential downstream work.

Typed operation definitions

• Action types. Customers define operation classes rather than relying on free-form prompts.
• Parameter types. Fields are validated against typed Action Schemas.
• Business identifiers. Invoice, account, resource and other business identifiers form part of operation semantics.
• Source mapping. Requests from supported sources map to declared canonical operations.

Customer-defined business vocabulary

• Business object types. Define customer-specific objects, identifiers, attributes and classifications as typed security inputs.
• Relationship semantics. Represent ownership, organizational, account, contract, asset and resource relationships.
• Authority dimensions. Expose customer-defined business permissions and relationships to deterministic Policy evaluation.
• Extensible schemas. Extend the authorized operation vocabulary through versioned configuration without changing Runtime core code.

Resources and protected values

• Target binding. The target resource and destination are explicit authorization inputs.
• Protected fields. Security-sensitive parameters are identified as protected operation values.
• Schema limits. Permitted values, sizes and structures are enforced before release.
• No hidden substitutions. Changing a protected recipient, resource or amount changes the operation that requires authority.

Restricted policy definitions

• Typed expressions. Policy evaluates declared types and operation fields.
• Static validation. Invalid constructs are rejected before activation.
• Controlled operations. Policy execution uses a restricted language, not arbitrary customer code.
• Explicit units. Amount, currency and unit comparisons require compatible semantics.

Independent authorization decisions

• Delegated authority. Policy operates within the effective authority of the requesting principal.
• Trusted context. Identity, scope, facts, detection and operation meaning are evaluated together.
• Deterministic results. The same trusted inputs and active configuration produce the same decision.
• No authority minting. Policy may narrow authority but cannot create authority absent from the identity chain.

Explicit Runtime decisions

• ALLOW / DENY. Permit or refuse an operation under explicit conditions.
• HOLD. Pause a protected operation under the defined hold workflow.
• RESTRICT / REDACT / TRANSFORM. Apply bounded constraints to permitted content or operation values.
• FLAG. Record a defined security finding without equating it to authorization.

Policy obligations and binding

• Mandatory checks. Operations cannot bypass required schema, identity or security checks.
• Verification requirements. Policy can require independent external facts before release.
• Binding requirements. Policy can require exact protected-field and destination binding.
• Release eligibility. A decision does not itself execute an operation or bypass Protected Release.

Policy testability and traceability

• Policy version references. Decision Evidence identifies the active policy and configuration generation.
• Decision reasons. Defined reason codes distinguish denial, restriction and failure.
• Negative-case testing. Policy validity includes rejection of forbidden and inconsistent inputs.
• Boundary tests. Permitted limits can be evaluated against expected outcomes before activation.

Shadow evaluation and impact simulation

• Parallel policy evaluation. Evaluate candidate Policy alongside active Policy without changing live authorization or release.
• Decision change analysis. Identify operations that would become allowed, denied, held or restricted under a candidate Policy.
• Requirement differences. Compare verification obligations, binding rules and security constraints before activation.
• Non-enforcing simulation. Test candidate decisions using representative inputs and permitted structured security context.

Customer-authorized external facts

• Source registry. External fact sources are explicitly registered and scoped.
• Read-oriented access. Verification uses bounded database and API reads rather than business-action execution.
• Credential separation. Verification credentials are isolated from the customer executor.
• Destination controls. Only declared verification destinations may be contacted.

Verified fact handling

• Typed facts. Returned external data is normalized into defined fact types.
• Source attribution. Verified facts retain source identity and provenance.
• Currentness. Policy uses fact freshness and validity under explicit requirements.
• Unavailable facts. A missing verification result cannot become a positive authorization fact.

Verification as a policy condition

• Required checks. Policy can block release until configured facts are verified.
• Read-only boundary. Verification does not transfer authority to modify a business system.
• Parameter correspondence. A fact must correspond to the operation and business object being checked.
• Failure outcomes. Verification failures yield explicit deny or hold behavior according to policy.

Automated HOLD and integrity Safety Review

• Automated HOLD. An Event awaiting required external facts or current security state remains held and cannot execute.
• Narrow human review. Safety Review addresses exceptional duplicate-Intent or operation-integrity ambiguity, not ordinary business approval.
• Protected operation integrity. A reviewer may resolve the ambiguity or cancel a candidate, but cannot rewrite its operation, protected binding or delegated authority.
• No human authorization. A reviewer cannot override Policy, grant or expand authority, issue a Release Grant or perform Protected Release.
• Fresh automated decision. Any candidate returned from review undergoes current identity, delegation, Policy and required External Verification checks.
• Separate Evidence. Review dispositions remain distinct from automated authorization decisions and Protected Release events.

Full reauthorization after HOLD

• Current-state reevaluation. A held operation is reconsidered against the current principal, delegation, security configuration and deterministic Policy.
• Fresh external facts. Required external information is reverified for the exact business operation before authorization.
• No carried approval. A previous ALLOW, a human integrity-review disposition or a changed customer-side fact does not itself authorize release.
• Exact Intent continuity. The original Intent identity and protected operation binding remain intact through reconsideration.
• Automated reconsideration. Authoritative external-state changes can trigger reevaluation without turning customer facts into Arximus authorization.

Protected connector registry

• Declared destinations. Protected operations use approved connectors and release destinations.
• Typed connector scope. Each connector has a defined operation and destination contract.
• Destination isolation. Connector configuration does not grant access to arbitrary networks or resources.
• Customer-side execution. Execution remains with the customer-controlled destination.

Stored protected functions

• Versioned artifacts. Protected execution functions are stored as immutable, versioned artifacts.
• Exact function identity. Authorization identifies the precise function and artifact version.
• Controlled artifact release. An authorized artifact may be released to a customer executor without running inside Arximus.
• Artifact integrity. Protected function content is bound to an integrity identity.

Submitted exact operations

• Customer-supplied operation. The customer application submits a concrete operation for authorization.
• Canonical serialization. The operation is normalized to an exact, reproducible representation.
• Protected parameters. Security-sensitive fields remain part of the authorized operation identity.
• Destination binding. Changing the execution target requires a different authorized binding.

Release grants and eligibility

• Current release eligibility. Grant issuance requires current applicable authorization, principal and delegation state.
• Exact operation binding. A Release Grant is bound to a specific canonical operation and protected values.
• Scoped authority. Grant validity includes the authorized scope, purpose and release destination.
• No release on unresolved HOLD. A held or unresolved integrity-review candidate cannot receive ordinary release authority.
• Decision-to-release separation. A positive Policy decision does not itself publish an operation or permit business execution.
• Release-state enforcement. Protected Release validates authoritative grant state and applicable continuing authority requirements.

Single-use release

• One-time authority. A release grant cannot authorize an unlimited number of executions.
• Atomic consumption. Concurrent attempts cannot consume the same release permission twice.
• Replay resistance. Previously consumed or invalid grants are rejected.
• State-bound validity. Release eligibility is checked against authoritative state.

No operation substitution

• Exact parameters. Release proof binds the authorized operation parameters.
• Exact destination. A grant for one execution destination does not authorize another.
• Artifact version. Mode A releases include the authorized protected artifact identity.
• Protected value verification. Customer executors can verify correspondence with the authorized binding.
• Changed operations require new authority. Altered recipients, destinations, protected values or artifacts cannot reuse a prior exact-operation binding.

Controlled release handoff

• Exact authorized operation. Only an eligible operation with a valid, exact binding can be released to its designated executor.
• Atomic publication. Release availability and single-use grant state remain consistent.
• Explicit release status. An attempted release is distinguished from a completed release.
• Failure integrity. Interrupted or retried handoffs cannot create a second authorized release.
• Customer-controlled execution. Arximus authorizes and releases the bound operation; customer-controlled systems perform the business action.

Trusted release-path enforcement

• Optional component. Arximus Lock is an additional customer-side control, not a requirement for normal Runtime use.
• Trusted-path validation. The customer can require proof of an authorized Arximus release before execution.
• Exact-operation matching. The executor verifies that the received operation matches the protected binding.
• Grant verification. Customer-side controls validate the relevant release proof and use state.
• Defined enforcement scope. Lock validates the execution paths where customer-side release enforcement is integrated.
• Executor conformance. Verification checks release proof, destination and exact-operation correspondence against the executor contract.

Layered customer-side enforcement

• Layered bypass resistance. For integrated execution paths, Arximus Lock can combine protected-artifact access, credential isolation, destination controls and Release Proof verification.
• Credential isolation. Business-action credentials remain within customer-controlled execution systems.
• Protected function access. Mode A execution can be bound to the specifically authorized protected function artifact.
• Restricted direct routes. Customer enforcement can close alternate paths that would otherwise bypass the authorized release route.
• Fail-closed execution. Integrated executors can refuse consequential operations without valid, exact-match release proof.
• Integration-specific scope. The protection applies to customer execution routes actually integrated with these controls.

Causal Evidence

• Event identity. Decisions and release transitions are tied to a specific Runtime Event.
• Causal references. Related operations and state changes retain explicit links.
• Decision Evidence. Policy outcomes and their security basis are separately recorded.
• Release Evidence. Grant, publication, consumption and failure events remain distinguishable.
• Observed versus reported outcomes. Arximus-observed authorization and release remain distinct from customer-reported downstream execution.

Integrity-protected records

• Immutable evidence objects. Evidence uses immutable record objects with integrity metadata.
• Cryptographic hashing. Record content and relationships support tamper detection.
• Scope partitioning. Evidence ownership stays bound to the originating security scope.
• Verification references. Integrity verification can follow explicit event and record references.
• Customer-scoped export. Evidence can be exported for customer investigation and independent verification under scoped access.

Cryptographic checkpoints and verification proofs

• Signed Evidence checkpoints. Generation-based cryptographic commitments protect the integrity and order of Evidence records.
• Membership proofs. Verification proofs establish the inclusion of a specific Evidence record within a signed checkpoint.
• Portable verification. Customer-scoped Evidence bundles can contain records, causal references, proofs and trust material for independent review.
• Optional external anchoring. Checkpoint commitments can be anchored outside the primary Evidence domain without disclosing raw customer content.

Content and evidence separation

• Zero-retention default. Ordinary AI Content is not retained by default.
• Separate Evidence. Security Evidence follows distinct handling and retention rules.
• Controlled forensic capture. Exceptional payload capture requires defined scope and authority.
• Data-class-specific deletion. Content, operational metadata and Evidence have separate lifecycle controls.

Separation of editing and authority

• Management is not Runtime authority. Customer configuration may be edited in the Control Plane, but mutable management records do not grant Runtime permission.
• Validated source. Configuration is validated and captured before becoming eligible for authorized Runtime activation.
• Signed active state. Runtime evaluates authorized configuration bundles rather than treating Control Plane tables as current Policy.
• Control Plane compromise containment. Access to Control Plane data alone cannot activate unauthorized Policy or manufacture valid Protected Release authority.
• Independent enforcement. Runtime authorization and Protected Release retain separate authority boundaries.

Immutable Runtime bundles

• Signed bundles. Runtime configuration is protected by cryptographic signing.
• Exact bundle identity. Version, digest and security scope identify the authorized configuration.
• Controlled publication. Publishing configuration is distinct from activating it.
• Trusted distribution. Runtime nodes verify configuration authority before use.
• Configuration provenance. Every active signed bundle traces to its validated source snapshot and authorized security scope.

Activation and rollback

• Activation generations. The effective security configuration is established by explicit authoritative activation state.
• Anti-rollback. An older signed configuration cannot silently replace the currently authorized generation.
• Authorized rollback. Restoring a previous Policy requires a new authorized activation, not replay of an old bundle.
• State-based authority. The passage of time or an application-local clock does not independently activate or restore permissions.
• Known-good recovery. Recovery accepts only explicitly authorized configuration state.
• Activation Evidence. Security configuration changes record the activated generation and its authorized transition.

Canonical security scope

• Tenant ownership. Every protected resource belongs to an explicit Tenant.
• Project boundaries. Projects define narrower ownership inside the Tenant.
• Environment separation. Production, staging and other environments retain separate authority scope.
• Trusted scope resolution. Scope is established from authenticated authority, not from an untrusted request field.

Cross-boundary protection

• Cross-tenant rejection. References to objects owned by another Tenant are rejected rather than repaired.
• Cross-environment enforcement. An operation cannot silently cross an Environment boundary.
• Scoped evidence. Evidence follows the ownership scope of the Event it records.
• Scoped cryptographic authority. Security scope applies to the validity of signed and protected objects.

Isolation beyond the database

• Runtime isolation. Request state and caches remain scoped to the originating Tenant and Environment.
• Configuration isolation. Policy and integration configuration cannot be resolved from another security scope.
• Release isolation. Protected operations and grants retain the scope established at intake.
• Recovery isolation. Restore and migration paths must preserve ownership and revoked state.

Arximus-native human identity

• Possession-backed identity. Privileged users authenticate through locally held, Arximus-registered cryptographic identity files.
• Local private-key control. Signing occurs locally; reusable human private signing keys are not supplied to the Control Plane.
• Challenge-response. Authentication verifies possession against a server-issued cryptographic challenge.
• Separate identity authority. External identity assertions cannot independently establish privileged Arximus authority.
• Proof-bound sessions. Protected administrative requests remain bound to verified possession and current server-side authority.
• Credential revocation. Revoked or replaced credentials cannot continue authorizing privileged sessions.

Sensitive administrative actions

• Action-scoped privilege. Sensitive operations require authority for the particular action.
• Separation of duties. High-impact control is separated from ordinary account administration.
• Protected recovery. Recovery and emergency authority do not bypass the security model.
• Administrative Evidence. Privileged changes produce distinct security records.

Quorum-controlled privileged operations

• Independent authorization. Highest-risk security changes can require contributions from multiple privileged identities.
• Configurable quorum. Sensitive actions support explicit multi-party authorization thresholds and separation of duties.
• Protected security changes. Trust-root changes, release shutdown or reactivation and emergency authority can require quorum control.
• Action-bound Evidence. Each authorization contribution remains bound to the exact privileged action and its security history.

Authenticated Runtime intake

• Application authentication. Runtime requests enter through authenticated application access.
• Trusted scope binding. Tenant and Environment scope are resolved before protected processing.
• Canonical intake. External requests are normalized into a common internal security Event.
• Admission failures. Invalid authentication, ownership or protocol state prevents trusted intake.
• Provider credential separation. Customer provider credentials remain distinct from Arximus application credentials.
• Controlled provider connections. Provider access follows registered destinations and purpose-bound credential authority.

Versioned external protocol support

• Protocol profiles. External API formats are handled through explicitly versioned profiles.
• Strict parsing. Unsupported, invalid and ambiguous wire formats fail explicitly.
• Canonical mapping. Protocol-specific fields map to shared Arximus security semantics.
• Response adaptation. Outbound responses retain the semantics of the selected protocol.
• No silent downgrade. Unsupported protocol versions are refused rather than mapped to weaker interpretations.

SDK contracts and event integrations

• Typed SDK contracts. Client integrations use explicit request, response, version and streaming contracts.
• Protocol negotiation. Supported versions and compatibility are selected explicitly, without silent security downgrade.
• Versioned webhooks. Customer event and monitoring integrations use defined event profiles and authenticated delivery boundaries.
• Server-enforced authority. Client libraries and webhook messages cannot grant privileged scope or bypass Runtime authorization.

Security-aware streaming modes

• Pass-through. Eligible content can stream through under the active security policy.
• Hold-back. Emission can wait while necessary checks are completed.
• Full-buffer. Operations requiring complete inspection can buffer before release.
• Mode selection. Streaming behavior follows the applicable protocol and security requirement.
• Bounded processing. Streaming checks operate within declared processing and content limits.

Continuous streaming protection

• Continuous security context. Inspection retains context across successive chunks instead of evaluating each fragment in isolation.
• Cross-chunk detection. Configured checks can identify protected values split across multiple chunks.
• Consistent parsing. Partial streaming messages retain their security meaning during inspection.
• Interrupted streams. Cancellation and partial delivery preserve explicit inspection and release outcomes.

Tool and MCP operation security

• Scoped tool identity. Tool identity and its associated MCP server are preserved as distinct security inputs.
• Typed tool calls. Observed Tool operations map to declared Action Schemas, resource targets and destination constraints.
• Untrusted tool results. Registered tools do not automatically confer trust on their returned instructions or content.
• Output provenance. Tool results retain source, classification and taint information for subsequent Policy decisions.
• Enforcement boundary. Tool and MCP controls apply to paths visible to Runtime or connected through trusted customer integration.

Retrieval provenance and influence controls

• Per-source provenance. Retrieved information retains its knowledge-source identity rather than becoming anonymous AI context.
• Classification continuity. Security classifications remain available to Policy when retrieved material informs subsequent operations.
• Taint propagation. Untrusted retrieved context can constrain later generated actions or Tool proposals.
• Customer-specific inspection. Custom security logic, classifications and registered analysis sources provide structured findings for retrieved content under the applicable runtime policy.
• Observed-source boundaries. Authoritative retrieval provenance requires observed retrieval or a trusted integration context.

AI memory read and write controls

• Memory-read provenance. Observed memory reads preserve source identity, classification and trust status.
• Security-state continuity. Sensitive or untrusted context does not become trusted merely by being stored and recalled.
• Protected memory writes. Observed consequential memory writes can become typed operations requiring deterministic Policy authorization.
• Retention authority. Sensitive memory persistence follows the applicable customer security and retention configuration.
• Taint persistence. A storage change or removal of raw content does not automatically clear security-relevant classifications or taint.

Secrets and sensitive values

• Secret detection. Known secret and credential structures are detected through deterministic checks.
• Customer patterns. Customer-defined matching rules extend detection to proprietary data formats.
• Forbidden values. Explicit value restrictions apply to configured operation fields and content.
• Protected destinations. Destination rules restrict movement of sensitive values.

Structured data controls

• Structured PII. Personal-data patterns can be classified and tested against active Policy.
• Field classification. Typed operation fields can carry explicit security classifications.
• Schema signals. Invalid data shape and parameter boundaries produce security facts.
• Customer-defined classes. Customers can define content categories relevant to their environment.

Provenance and taint

• Source provenance. Signals distinguish verified sources from client claims and AI-generated content.
• Trust descriptors. Context values carry typed trust information.
• Taint propagation. Untrusted or sensitive data labels can affect downstream operation decisions.
• Authority separation. A detection result is a fact for Policy, not a grant of permission.

Redaction and transformation

• Redaction. Configured policies can require removal of specified sensitive content.
• Transformation. Typed transformation outputs must pass validation before use.
• Restriction. Policy can narrow permitted operations or fields.
• Flagging. Security-relevant content can be marked without being treated as automatically denied.

Organization-specific runtime security and authority

• Customer-defined security logic. Define sophisticated security and authority models around your own identities, actions, resources, business objects, relationships, classifications, operational limits and trusted security context. Arximus adapts to the requirements of the organization without imposing a fixed business vocabulary or authority model.
• Advanced security composition. Combine universal security functions into deeply layered, interdependent requirements across exact-operation constraints, conditional restrictions, separation of duties, multi-party approvals, quantitative limits, trusted historical state, source provenance and risk conditions. Multiple conditions can be evaluated together to enforce precise, organization-specific security decisions.
• Runtime analysis and information control. Configure deterministic threat detection, content inspection, classifications, information-flow restrictions and comprehensive parsing, enrichment, redaction and transformation workflows. Apply these controls at supported processing stages, with resulting information validated before influencing security decisions or continuing through protected paths.
• External intelligence and independent enforcement. Incorporate authoritative facts, business-system state, approval records and specialized security findings through registered integrations and External Verification. Arximus evaluates the complete security context through deterministic, signed and versioned policy, while delegated authority, exact-operation binding and Protected Release remain independently enforced.

Advanced runtime analysis and private intelligence

• Customer-defined security analysis. Define sophisticated inspection and detection requirements across AI requests and responses, tool and MCP operations, retrieved context, memory, streaming content and protected information flows. Combine deterministic detectors, classifications, provenance, risk indicators and interdependent conditions to identify threats and security-relevant behavior specific to your environment.
• Semantic intelligence and structured findings. Incorporate customer-selected models, classifiers and specialized analysis services to assess suspicious instructions, prompt injection, context manipulation, semantic exfiltration and other meaning-based threats. Combine semantic findings with deterministic analysis and runtime context, preserving source identity, trust status and structured evidence for subsequent security decisions.
• Private enrichment and information control. Integrate proprietary business systems, internal registries, operational state, approval records and authoritative external sources to enrich security context with organization-specific intelligence. Compose parsing, enrichment, redaction and transformation controls to process, classify and protect information before it influences downstream security decisions or moves through protected paths.
• Independent policy and enforcement. Bring security findings, classifications, enriched context, trusted relationships and externally verified facts together under deterministic Arximus Policy. Customer-defined analysis informs authorization without expanding delegated authority or independently granting permission. Security-relevant modifications remain subject to revalidation, exact-operation binding and independently controlled Protected Release.

Compromise containment and enforced security boundaries

• Independent security domains. Arximus separates configuration, runtime security analysis, External Verification, authorization, cryptographic authority, Protected Release and evidence across independently constrained trust boundaries. Compromise of an individual component, security input or tenant does not automatically provide access to other security domains or unrestricted platform authority.
• Authority containment. Every operation remains subject to verified identity, effective delegation, resource restrictions and applicable security policy. Customer-defined logic, classifications, external findings and information transformations can impose additional requirements but cannot independently expand delegated authority, bypass mandatory restrictions or issue Protected Release authority.
• Controlled security processing. Sophisticated policy composition, deterministic inspection and information-processing workflows operate within defined resource limits, validated data contracts and controlled execution boundaries. Security evaluation remains bounded and isolated from privileged platform capabilities, while access to authoritative external systems follows explicitly governed verification paths.
• Fail-safe enforcement. Missing evidence, conflicting facts, incomplete inspection, failed security requirements and unavailable verification sources cannot silently become permission. Arximus applies the required denial, hold or recovery behavior while preserving independent authorization, transformation revalidation and exact-operation binding before Protected Release.

Controlled policy and traceable security evidence

• Runtime context. Every evaluation uses the identified Runtime Event, applicable trusted security state and active policy configuration.
• Validated requirements. Function inputs, outputs, conditions and dependencies are checked against structured, versioned contracts.
• Controlled configuration. Signed activation, configuration versions and revocation requirements determine which policies have authority in production.
• Evidence provenance. Security findings retain the identity of their native detector or registered external source, together with their applicable trust status.

Policy remains the final authorization authority

• Delegated authority. Customer-defined security logic operate within the permissions and restrictions actually delegated to the machine actor.
• Independent Protected Release. Security findings, classifications and external facts cannot independently issue Release Grants or authorize protected execution.
• Customer-controlled execution. Business operations remain within customer-controlled execution infrastructure, separate from Arximus authorization and release authority.
• Deterministic decisions. Applicable Policy evaluates the complete set of trusted requirements to determine whether the exact operation may proceed.

AI systems and dependencies

• Model and provider inventory. Track connected AI models and providers.
• Application and agent inventory. Represent applications, agents and tools operating in a customer environment.
• MCP and resource inventory. Track MCP servers, destinations, protected resources and knowledge sources.
• Relationship mapping. Inventory records include known relationships and credential references.

Inventory confidence and source

• Observed. Facts directly seen at the Runtime boundary are distinguished from declared configuration.
• Configured. Customer-declared inventory entries retain their configured origin.
• Attested. Customer or authorized-source assertions retain their declared provenance without being treated as independently verified observations.
• Inferred. Inferred relationships are not represented as direct observations.

Purpose-separated trust

• Typed signed objects. Signatures are bound to their object type and cryptographic purpose.
• Trust domains. Signing and encryption authority are separated by defined domains.
• Scoped verification. Cryptographic checks include intended scope and applicable trust generation.
• Profile versioning. Approved cryptographic profiles have explicit version and lifecycle state.
• Key trust lifecycle. Cryptographic keys and trust generations support controlled rotation, revocation and compromise response.

Separated security authority planes

• Independent security domains. Customer management, Runtime authorization, Protected Release and Evidence have distinct authority boundaries.
• Control Plane containment. Compromise of management data or ordinary Control Plane access does not itself confer signing, activation or release authority.
• Release independence. Authorization components cannot unilaterally issue or consume Protected Release authority.
• Purpose-bound trust. Security operations require the appropriate cryptographic purpose and currently authorized scope.
• Cross-domain integrity. A compromise in one service cannot silently expand permissions across unrelated security domains.

No restoration of revoked authority

• Restore barriers. Recovery cannot treat stale stored state as current authorization.
• Consistent replay. Durable event processing handles redelivery without duplicating a logical operation.
• Protected backups. Backup and restoration preserve integrity and isolation requirements.
• Explicit failure policy. Missing critical state yields a defined refusal, hold or other approved failure outcome.
• Transactional authority. Critical authorization and release state changes remain durable and consistent across retries and recovery.
• Cache non-authority. A cache failure, stale entry or restored snapshot cannot create or reinstate permission.

Multi-tenant Runtime cells

• Runtime cells. Customers are placed in security-bounded Runtime cells.
• Cell assignment. Tenant-to-cell placement is explicit.
• Cell-specific authority. Each cell uses its own workload, network and cryptographic security context.
• Blast-radius boundaries. Cell isolation limits the impact of a cell-level incident.

Regional placement and continuity

• Regional Runtime. Deployment architecture defines regional Runtime placement.
• Regional data boundaries. Content, state and Evidence placement follow defined regional requirements.
• Failover consistency. Regional recovery cannot silently weaken protocol, Policy or trust semantics.

Dedicated customer environments

• Dedicated deployment. Enterprise configurations can use single-tenant Runtime environments.
• Separate key domains. Enterprise key and trust isolation can be configured independently.
• Retention controls. Customer-specific Evidence and retention requirements can be incorporated.

Private ingress and egress

• Private ingress. Customer traffic can enter through a defined private connectivity path.
• Private egress. Connections to required systems can be restricted to approved private routes.
• Private verification. External Verification can connect to customer-controlled private sources.
• Private release. Protected Release can use approved private executor connectivity.

Customer security operations

• SIEM integration. Security events can be delivered to customer monitoring systems.
• Evidence export. Enterprise workflows can receive scoped security Evidence.
• Directory integration. Enterprise directory information can be integrated without becoming native Arximus identity authority.
• Monitoring hooks. Service-level and security telemetry support customer operations.

Security telemetry

• Runtime events. Security telemetry includes defined event classes and contextual metadata.
• Anomaly indicators. Impossible or inconsistent privileged behavior produces a security signal.
• Canaries and tripwires. Dedicated security signals reveal unexpected access and potential compromise across protected trust boundaries.
• Scoped monitoring. Monitoring retains the relevant Tenant, cell and security-domain context.

Independent emergency release control

• Independent release shutdown. A separate security authority can stop Protected Release without relying exclusively on normal Control Plane operation.
• Restriction precedence. Current emergency restrictions take priority over previously active configuration and release eligibility.
• Scoped emergency containment. Security response can restrict affected authorization and execution pathways.
• Protected restoration. An independently authorized stop cannot be cleared by ordinary management action alone.
• Incident Evidence. Emergency restriction and restoration produce traceable security events.

Controlled failure behavior

• Dependency failures. Unavailable identity, Policy or critical state does not silently become permission.
• Resource exhaustion. Capacity and overload conditions are handled under explicit failure rules.
• Isolation failure. Cross-domain integrity failures produce security events and bounded impact.
• Known-good state. Recovery restores only still-authorized security configuration.

Complete customer technical specification

Platform capabilities, configuration requirements, authority models, exact operation semantics, decision outcomes and deployment requirements.

Trust and enforcement architecture

Security-domain isolation, privileged authority, cryptographic trust, release enforcement and integration-specific protection boundaries.

Protocol and integration specifications

API profiles, protocol versions, Event and Action contracts, authentication, streaming behavior and customer integration requirements.

Policy, Verification and data controls

Detailed Policy constructs, supported external-fact sources, HOLD conditions, content handling, Detection rules and transformation constraints.

Protected Release and executor integration

Mode A and Mode B executor contracts, cryptographic release proofs, exact-operation validation and Arximus Lock integration.

Enterprise deployment and private connectivity

Environment isolation, key boundaries, regional placement, private networking, Evidence integration and customer-specific service requirements.

Threat model and resilience boundaries

Trust-domain design, compromise detection, incident containment, secure recovery and integration-specific assurance boundaries.

Security Verification & Conformance

Detailed security validation covering identity, deterministic Policy, tenant isolation, Protected Release, replay resistance, failure handling and recovery. Technical evaluation includes verification requirements, conformance criteria and security testing scope.