A boundary around supported effects
Nikxius controls supported, enrolled operations that execute through the customer Runtime. It does not make an AI system safe in general. The security claim depends on verified identities, constrained native credentials, trustworthy Node behavior and a deployment that closes alternate write paths.
The agent proposes an operation. The customer Node checks its authority and native preconditions, records the possible dispatch, and uses the protected resource credential. Existing native authorization and admission still apply.
Responsibilities by boundary
| Boundary | Responsibility |
|---|---|
| Agent / automation | Submit a typed proposal under a registered workload identity; receive no native resource credential |
| Identity provider and registration | Authenticate accepted principals and their tenant/role mappings |
| Runtime policy and grant | Bind supported operation, exact target/effect, expiry and required review |
| Customer Node | Validate trusted state, freeze request, persist dispatch and retain outcome evidence |
| Native API and policy | Enforce native permissions, conditional updates and admission behavior |
| Customer operators | Establish exclusive write paths, controller ownership, retention and emergency response |
An asserted identity in an agent trace is not equivalent to an authenticated caller. A tenant field supplied by the proposer is not accepted as the tenant boundary. The current customer API validates identity independently and scopes records accordingly.
Credential exclusivity
The protected native token belongs on the customer Node, not in an agent prompt, tool response or browser storage. Review all alternate routes: other Kubernetes tokens, readable Secrets, token creation, exec/shell access, privileged tools, CI jobs and independently credentialed agents.
RBAC constrains resources and verbs; the trusted adapter constrains the permitted patch fields. Native admission and controller behavior need their own review. A privileged administrator, compromised Node or trusted admission component can violate assumptions that an operation-level runtime does not independently control.
Nikxius does not automatically discover every bypass. A deployment review must establish the boundary before relying on it. This is why the initial offer starts with one named nonproduction environment.
Exact authority and native state
The supported operation, enrolled target, task grant, frozen policy and required review must agree on the exact effect. The Node independently reads current native state and binds resource identity and version. Changed parameters under a repeated proposal key are refused.
Native conditional updates are necessary but limited. They do not create a transaction across PostgreSQL and Kubernetes, nor prove properties the contract does not inspect. A local worker lease cannot retract a request already sent. Revocation prevents newly admitted or dispatched work under the documented lifecycle; it is not a universal remote cancellation mechanism.
Human review
Where policy requires review, the current command version and semantic/dispatch hashes bind the decision. Caller-supplied reviewer identity, approval timestamp or MFA assertion is not a substitute for registered identity and accepted policy.
Policy may permit bounded autonomy without another human approval. The product does not claim every action requires a human. The current browser session handoff is also not a complete enterprise SSO redirect implementation; customer identity integration remains part of validation.
Uncertainty is retained
After possible Kubernetes dispatch, the Runtime reconciles using native observations rather than blindly reissuing the mutation. Missing or compacted history can leave UNKNOWN indefinitely. Such an operation retains its relevant reservation; the API has no “reset unknown” shortcut.
Emergency access should preserve the original record and follow the customer’s incident process. A later repair does not prove the original action never happened. A restored database snapshot may omit already committed external effects and must not be treated as a clean new authority ledger.
What signed evidence establishes
Optional Node signing protects attribution of the exported records to an accepted key. A verifier must authenticate its trust material separately. Signatures do not independently establish that a native observation was true, that no action was omitted, that an application became healthy or that a legal obligation was satisfied.
Evidence remains a capability of the execution lifecycle. It cannot create missing prior authorization or recover native history that was never retained.
Current validation and scope
The dated local verification record reports controlled local conformance, not a security certification, third-party audit or customer production approval. Synthetic identity fixtures and a disposable Kubernetes environment have explicit limits. Real HCP account validation remains pending.
The public website runs a recorded demonstration. It does not request visitor infrastructure credentials or submit production operations. The Payment Evidence reviewer remains a separate browser-local reference tool under its stricter no-connection policy.
Read the current Runtime contract, action-contract technical note and recovery model. For an evaluation, begin with one operation and its existing write path.