Authority as a checked property

This chapter describes a mechanism rather than a syntax. The language surface is not yet frozen, and publishing it early would teach a moving target to the model corpora that are the finished language's intended audience. What follows is what is guaranteed, and why it follows.

Section 01The problem with ambient authority

In every mainstream language, the ability to reach the outside world belongs to the process, not to the code. Any component can, in principle, open a socket, read a file, or query a database — not because it was granted permission, but because nothing prevents it.

This is why the questions your architects care most about have no good answers today. What can this component reach? is answered by reading imports and configuration and inferring. What could this dependency do? is answered by reputation. What bounds a compromised component? is answered by the process boundary, which is far too coarse to be useful.

Two serious industry attempts to fix this after the fact both failed, in the same way: process-granular permission flags cannot express this module may reach this resource, and a runtime permission architecture in another major platform was withdrawn after years of effort. Per-component authority cannot be expressed at process granularity and cannot be retrofitted at runtime.

Section 02What replaces it

Every ability to affect the world is an explicit, unforgeable value that must be handed to code before it can act. Not a permission checked at runtime — a thing you either hold or do not, and which cannot be manufactured, guessed, or obtained by asking.

Code that was never given the database cannot query it. The program that does is not a program.

Three properties follow directly, and they are the ones worth testing the claim against:

• It is established before the code runs, not enforced while it runs. There is no runtime check to bypass, no policy engine to misconfigure, and no failure mode in which the guard was not on the path.
• It is complete. What a component can reach is enumerable by the compiler, because there is no ambient channel that fails to appear in that enumeration.
• It survives the author being wrong. The property holds whether the code was written by a careful engineer, a careless one, or a model acting on instructions somebody else supplied.

Section 03Scoping is where it earns its keep

An authority is not merely the database. It can be issued already narrowed — to one tenant, one customer, one case, one classification — at the moment it is minted.

Code holding a narrowed authority cannot widen it. There is no operation that converts a customer-scoped data authority into an unscoped one, because that operation does not exist. So the cross-boundary read — the finding every multi-tenant operator fears, and the one that produces a regulatory notification rather than a vulnerability ticket — stops being a defect testing might catch and becomes a program that does not build.

This is the single property most worth interrogating when you evaluate this work, and it is the one the programme's benchmark is built to attack.

Section 04One mechanism, several payoffs

A design budget spent on one mechanism has to pay more than once.

Contained injection

An influenced author cannot obtain authority it was not given, so the blast radius is bounded to what the task legitimately required.

Credentials that are not strings

A secret held as an authority cannot be printed, serialised or logged by code that was not given it. Nothing in the repository to find; nothing in the environment to enumerate.

Derivable placement

What code may be handed determines where it may run, so tier boundaries are computed rather than maintained. Chapter 13.

Dependency permissions

A component's authority requirements become part of its checked signature — a static property a reviewer can read and a checker enforces. Chapter 15.

Answerable audit questions

"What can this reach?" becomes a query with a complete answer, produced mechanically rather than assembled by interview.

Section 05The cost, and the budget that bounds it

Every departure from what models already know is a tax paid on every build, forever: a model writing an unfamiliar construct performs measurably worse than the same model writing a familiar one. Ignoring that is how clean-slate language projects fail, and it is the strongest argument against this one.

So the programme keeps a binding ledger of every departure, priced, with a hard cap and rules deliberately awkward for us:

• A restriction — a rule making fewer programs writable — prices nothing, because a model that never saw the forbidden form loses nothing by its absence. But only if the toolchain can report the violation with a real diagnostic. A restriction the compiler cannot explain is a trap, and it forfeits the discount.
• A rental — reusing a construct the major training languages already have — also prices nothing. But the comparison set is named and fixed, and searching outside it does not count.
• The ledger may be tightened at any time, and loosened only by a written decision at a phase gate.

It currently sits at its cap, with no headroom. A new departure requires removing an existing one. That is published because it is the discipline most likely to be quietly abandoned, and a budget that only grows is not a budget.

Section 06The design has already been changed by its own testing

The mechanism as first designed included a subtle rule about how these authorities may be carried around. It was better than the alternative on every axis except one, and a pre-registered adversarial test found it: a model that violated the rule could not be told what to do about it clearly enough to repair it reliably.

The pre-registered fallback — a blunter, stricter rule that forbids more than it strictly needs to — passed where the subtle one failed, so that is what the first version carries. The subtle rule may return later, strictly as a relaxation, and only on measured evidence.

This is recorded because it is the most useful thing to know about how the work is conducted: a rule whose diagnostic a machine cannot act on is a failed rule, however elegant — and it is far cheaper to discover that at specification stage than in a compiler.