LNSAT: Authority for Agent Actions

The documented authority contract

LNSAT is pre-release open-source 0.1.0 source for policy-governed execution authorization and evidence. Its public design starts with an exact, versioned action packet: an actor, target, operation, parameters, applicable limits, and evidence inputs. The packet describes the request that needs evaluation; it does not grant authority by existing.

That precision prevents a broad instruction from being treated as permission. A model recommendation, connector credential, or exposed tool can indicate technical capability, but none independently decides whether an external effect is permitted for a particular actor, target, payload, and scope.

Exact packets also make review scope visible. They give policy and approval a stable object to evaluate, while preserving the difference between an intended action and an observed outcome.

The packet binds related records together

A consequential request needs more than a command name. LNSAT's public model links the packet to the applicable policy outcome, any scoped approval, the resulting one-time authorization, the adapter result, and the observed outcome. These relationships preserve which evidence applied to the request rather than relying on a general memory that a similar action was allowed before.

A changed actor, target, payload, artifact digest, or permitted scope produces a different request. An older approval therefore cannot be reused as a standing credential for the altered action. The relationship record is valuable both before execution and when a later reviewer needs to understand why a request was allowed, denied, or left unresolved.

Hypothetical example: a reviewed status update

Consider a hypothetical workflow that drafts a customer-facing status update after a reviewer checks the underlying record. The proposed send could be represented as an exact packet containing the responsible actor, recipient target, message payload, permitted scope, and the evidence used for the review. Policy can then allow it, deny it, or require a scoped human approval for that specific request.

If the recipient, wording, relevant record digest, or scope changes after approval, the changed packet requires a new decision. In this hypothetical workflow, the sending application's adapter owns delivery and returns the result. The packet connects that operation to the policy decision, approval record, and later evidence.

Approval and evidence need explicit tests

The design calls for tests that preserve the authority boundary. Useful cases include a policy denial, an approval-required result with no approval present, an approval whose packet digest no longer matches, a consumed one-time authorization, and a receipt that binds to the same request identifiers. These tests check that a valid path is narrow, not that every requested action can proceed.

Evidence distinguishes policy evaluation from execution outcome. Packet tests cover consistent decisions and rejected approvals. Adapter tests cover the receiving interface, result states, and error handling. Deployment receipts identify the tested version and environment. Each record has a clear role in the release decision and in investigating a later failure.

The same discipline applies to approval interfaces. A reviewer should be able to identify the proposed action, the evidence used to evaluate it, the policy result, and the scope of any approval. A generic confirmation control is weaker because it cannot show which exact packet the person considered or whether later changes invalidated the decision.

Unknown is a first-class result

A timeout, disconnect, or partial failure produces a recorded outcome that needs investigation. LNSAT's public model routes unknown outcomes to reconciliation. The receiving system's records establish whether the action completed, failed, or needs further review before another attempt. This gives the operator a concrete recovery path and preserves the history of the original request.

Receipts connect the request, authorization, adapter result, and observed outcome so a reviewer can investigate the uncertainty. A denied request remains denied, and a failed or incomplete response remains evidence of a failure state until the relevant result can be reconciled. This preserves a clearer audit trail than a single generic completion flag.

Pre-release boundary and capability distinction

LNSAT is pre-release source for evaluation and development. Its engineering scope covers action packets, policy decisions, scoped approvals, one-time authorization, receipts, and reconciliation. MCP or another tool protocol supplies the operation interface; the owning application supplies the adapter and enforces the authorization decision at the point where the effect occurs.

Rangoon's development scope covers capability composition, compatibility planning, tests, and deployment planning. Its capability records make requested behavior and dependencies inspectable. LNSAT's design addresses the authority for one exact consequential request and the evidence for its result. Connecting these records gives integration design a clear sequence: capability definition, proposed action, policy decision, scoped approval, and outcome evidence.

Related capabilities

• SI agent governance and authorization
• Platform engineering and reliability