Product · Nikxius

Bind authority to an exact action

How Nikxius connects permitted effects, native state and dispatch through supported operation contracts.

Nikxius ResearchReviewed: 15 September 2026

Permission should describe the effect

An authenticated agent may still lack authority for a particular change. “Can call the Kubernetes tool” leaves the target, exact mutation, current state and failure behavior unspecified.

Nikxius uses supported operation contracts to connect those decisions. A contract is specific to a native operation. It defines the request shape, effect-bound grant, trusted baseline, required review, writer, outcome rules and recovery behavior.

The broader agent action contract is a public engineering framework. It synthesizes established controls; it is not a new industry standard or a claim that Nikxius invented exact-action authorization. Read the technical note for a detailed framework and current API mapping.

What is bound

The action contract binds who, what, where, native state, limits and review to dispatch, outcomes, uncertainty, recovery and evidence.

For the first rollback evaluation, the contract identifies one cluster, namespace, Deployment and container; one permitted immutable prior image; the exact prior operation being compensated; the resource UID and native version observed by the Node; and the current grant and review requirements.

The proposer does not choose its trusted identity, tenant or policy by supplying arbitrary JSON fields. The Node independently resolves those facts and the current native state. An approval must refer to the current exact command and dispatch binding.

What changes when a precondition changes

A resource recreated under the same name is a different identity. An intervening edit can invalidate the frozen baseline. Revoked or expired authority can prevent a new dispatch. Changed request parameters under the same idempotency key are refused.

These checks have a boundary. A local worker lease cannot retract a request already sent. A native precondition cannot prove application-level compatibility that it does not inspect. The contract must name those limits before an agent relies on it.

An operation is more than an allow/deny result

Once dispatch is possible, the question changes. The Runtime must distinguish a committed native effect, known rejection, later degradation and insufficient evidence. It retains the original operation identity through reconciliation.

That is why evidence is part of the lifecycle. An export relates the grant, exact request, required review, attempt and native observations. Optional signing protects attribution to an accepted Node key; it does not create truth or completeness.

Supported contracts are deliberately narrow

The current implementation has several typed profiles, each with explicit native semantics. The initial commercial evaluation focuses on one: Kubernetes image rollback. Other profiles are documented with their limits rather than presented as a universal connector catalog.

A ConfigMap data update does not prove consumer adoption. CronJob suspension does not cancel existing Jobs. HCP saved-plan apply admission does not prove cloud effects completed. A shared Runtime interface must preserve these distinctions.

Compare the complete contract

Existing policy engines, native permissions, application actions and workflow systems may already satisfy the requirement. Compare the exact contract, not whether one vendor uses “agent” in its category name.

The evaluation should ask whether Nikxius removes bespoke integration and unresolved-outcome work for this operation. Read the current API and scope, inspect the recovery model, or evaluate one operation.

Explore the action contract, the Kubernetes rollback workflow, or evaluate one operation.