LNSAT: Authority for Agent Actions

LNSAT is pre-release open-source 0.1.0 source for policy-governed execution authorization and evidence. Its model treats a consequential request as a bounded packet, evaluates that exact request, requires scoped approval when policy demands it, and preserves receipts and reconciliation evidence for known and unknown outcomes.

Hypler company update published October 6, 2026.

Topics: LNSAT, execution authorization, policy, scoped approval, evidence

Hypler logo LNSAT product logo

LNSAT authority architecture, a generated illustration rather than runtime evidence. Credit: Hypler / project editorial artwork. Hypler project artwork; not runtime evidence

LNSAT public GitHub repository captured October 5, 2026; pre-release source, not a running application. Credit: Hypler. Hypler project media; retain evidence qualifier

Engineering relevance

Tool access, connector credentials, and a model recommendation do not establish permission to cause an external effect. Binding policy, approval, authorization, and evidence to one exact request makes changes and uncertain outcomes visible instead of silently reusing prior context as authority.

The request must be exact before it can be evaluated

LNSAT represents a consequential request as a bounded, versioned packet. The packet identifies the actor, target, operation, parameters, applicable limits, and evidence inputs needed to evaluate that one request. Intent alone does not grant authority.

This framing makes material changes explicit. A request with a different target, actor, payload, artifact digest, or permitted scope is a different request. An earlier approval cannot be treated as a general credential for the altered action.

Policy and approval are separate from tool exposure

LNSAT evaluates a bounded packet through deterministic policy outcomes such as allow, deny, or approval-required. Where approval is required, a human decision binds the exact request rather than authorizing an open-ended category of work. A one-time authorization is then consumed for its intended action.

This distinction is especially important for systems that expose tools through MCP or other connector patterns. A tool can describe a possible operation, and credentials can enable technical access, without answering whether that operation may proceed for this actor, target, payload, and moment.

An illustrative consequential-action scenario

Consider an illustrative workflow that proposes sending a customer-facing status update after a reviewer has checked the underlying record. The proposed send can be represented as an exact packet with the responsible actor, recipient target, message payload, permitted scope, and evidence inputs. Policy can then deny it, allow it, or require a scoped human approval for that specific message.

If the recipient, message content, or relevant record digest changes after approval, the old approval no longer applies to the changed request. If delivery returns a timeout or partial response, the system should preserve an unknown outcome for reconciliation rather than calling it a success or automatically treating a repeat as safe. This is an architecture example, not a hosted dispatch claim.

Receipts make uncertain outcomes reviewable

Receipts connect the request, policy outcome, applicable approval, authorization, adapter result, and observed outcome. A denied request remains denied. A timeout, disconnect, or partial failure is not success merely because an operation was attempted.

Reconciliation exists to investigate ambiguity before an external consequence is treated as settled or repeated. LNSAT is pre-release source for evaluation and development, not a general production dispatcher, hosted runtime, published package, or unrestricted infrastructure control plane.