LNSAT: execution authority for AI agents
How Rangoon separates capability management from LNSAT execution authority, exact action packets, approvals, receipts, and state reconciliation.
Project architecture · Rangoon remains in active development; documentation checked October 3, 2026.
RangoonLNSAT
Key takeaways
- Rangoon manages capabilities, configuration, compatibility, and evidence; LNSAT evaluates authority for an exact operation.
- Approval and identity context inform a decision but do not replace server authorization or one-time redemption.
- Receipts and reconciliation make the requested, approved, executed, or unknown outcome reconstructable.
Capability is not authority[source 1][source 2]
Rangoon’s product model starts with capability management. An agent profile can contain instructions, skills, workflows, model choices, context, connector operations, tests, target assignments, and policy requirements. Those records explain what an agent is configured to request and where a bundle can be represented. They do not grant a blanket right to perform every operation described by a skill or connector.
LNSAT is the reference execution-authority and evidence engine in this architecture. It evaluates whether a specific proposed action may proceed, preserves the decision context, and binds the eventual result to evidence. Keeping these layers separate gives teams room to change a model, runtime, connector, or policy engine without silently changing the meaning of authority.
The packet makes a request exact[source 1][source 2]
An authority decision needs a bounded request rather than a vague instruction. The packet identifies the authenticated actor and session, project and environment, target resource, operation type, parameters, capabilities, risk, time bounds, nonce, idempotency key, and exact artifact or configuration digests. Effective instructions, skills, profiles, context, and model overlays contribute evidence to the configuration that produced the request.
That precision gives policy a stable subject. A policy input can distinguish a read from a write, one repository from another, one data class from another, and a short-lived request from an open-ended grant. Unknown fields, unsupported capabilities, incomplete evidence, stale versions, or widened scope fail closed instead of becoming permissive defaults.
Approval is a gate, not the authorization record[source 1][source 3]
LNSAT policy can return allow, approval required, or blocked. When approval is required, the approval record binds the exact request, approver, decision, scope, reason, and expiry. A human approval for one packet cannot authorize a changed digest, resource, actor, or capability. Identity providers and policy engines can contribute authenticated claims or policy results, but neither creates an execution grant by itself.
After the required checks, Gateway creates a server-side authorization and a one-time capability. The capability is represented by a protected digest and is atomically consumed before consequence. This redemption step closes a gap that a simple “allowed” boolean leaves open: replay, substitution, and use outside the approved scope become detectable authorization failures.
Connectors return evidence, not just success text[source 1][source 3]
The connector or adapter receives a bounded, authorized operation. Its contract declares inputs, outputs, side effects, idempotency behavior, target identity, and receipt obligations. The connector remains an external-system boundary; its credentials, network reachability, or catalog entitlement cannot widen the authority decision. OPA, Cedar, OpenFGA, OAuth, SPIFFE, MCP, and A2A can provide useful context or transport, but the exact action still passes through the selected authority path.
A receipt binds authorization and consumption identities, requested, approved, and executed digests, adapter and sandbox identity, start and end times, bounded result, and rollback evidence. If a timeout or disconnect leaves the external state uncertain, the system records outcome unknown and reconciles before treating the operation as settled or retrying it. The evidence chain is designed to answer what was requested, what was approved, what ran, and what can be proven afterward.
Example: a guarded GitHub change[source 1][source 4]
Consider an agent asked to update a repository. Rangoon can identify the agent profile, selected skill, repository context, target branch, connector operation, checks, and rollback expectation. The resulting packet can bind the exact repository, revision, patch digest, requested files, and declared side effect. A reviewer sees the proposed change and the policy requirements before an authority decision.
LNSAT then evaluates the exact packet, requests human approval when policy requires it, issues a one-time authorization, and lets a bounded adapter perform the GitHub operation. The adapter returns a receipt containing the operation identity, target, result, and evidence. A different branch, patch, actor, or payload produces a different packet and requires a new decision. The model’s recommendation or connector token never substitutes for that chain.
What this architecture does and does not claim[source 1][source 2][source 3][source 4]
The public Rangoon site explains this separation as launch architecture. It does not claim that every connector, signer, runtime adapter, installer, hosted service, or policy integration is shipped. Application source, versioned compatibility results, licenses, and release artifacts are the source of launch truth when published.
The useful engineering commitment is the boundary: capability records stay inspectable, policy input stays distinguishable from authority, approvals remain exact, one-time redemption prevents casual replay, and receipts preserve what happened or what remains unknown. Implementations still need their own tests, deployment controls, credential handling, monitoring, and release evidence.
