2.1.5 Authorization, Licensing, and Control

Allow 15 minutes for required external reading, 35 minutes for the lesson, and 25 minutes for the exercise and answer review. No code, software installation, GPU access, or cryptographic calculations are required. Read the specified excerpts, not the full documents. Inline references support factual claims; they are not additional reading assignments.

A Valid Permission Is Not a Compliant Workload

In 2.1.4, an operator presented a genuine authorization for a safety evaluation. That did not establish whether the work stayed within its scope. This lesson asks a further question: could a machine enforce the authorization before prohibited work happens?

There are two different objects here. A legal authorization is permission under an agreement or regulatory system. A license token is a machine-readable instruction that a device can authenticate and apply. A software subscription is a third, commercial use of the word “license.” None automatically substitutes for another.

Suppose an authority permits a specified evaluation on registered hardware, with no more than ten units of counted compute. A token might encode a device identifier and a numerical allowance. It does not acquire an understanding of “evaluation” merely because that word appears in the document from which it was generated.

The policy task is to establish both that the token accurately translates the permission and that the enforcement mechanism constrains the activity the rule actually covers. The authenticity, correctness, and completeness questions from 2.1.1 have not disappeared.

A Deployed Example: Permission Can Expire Without a Misconduct Finding

NVIDIA documents software-enforced licensing for its AI Enterprise vGPU for Compute virtual machines. In the release-8 documentation, a VM without a license initially receives a 20-minute grace period; an already licensed VM disconnected from the cloud license service has a default seven-day grace period. Performance degrades if licensing is not restored, and full capability returns when a valid license is acquired. These are different situations, not two descriptions of the same timer.

This is a real product behavior, not a reported enforcement incident. It illustrates a control that can restrict useful computation because permission is unavailable—not because anyone established prohibited use. The same distinction matters in a treaty system when a renewal server fails or a network route is interrupted.

It also illustrates the limit of the analogy. The documentation explicitly calls this software enforcement. It does not establish resistance to a hostile equipment owner, physical attack, or state-sponsored modification. Do not read it as evidence that installed GPUs already implement a treaty-enforcement switch.

From Commercial Licensing to Hardware-Backed Control

Kulp and colleagues’ 2024 RAND working paper proposes offline licensing: a device authenticates an allowance, meters its consumption, and restricts selected functionality when the allowance is exhausted. Tokens need not arrive through a live internet connection. The proposal separates this control from verifying what the permitted compute actually did. It is a design proposal, not evidence of an operating international regime.

Kulp et al., Hardware-Enabled Governance Mechanisms, RAND WR-A3056-1, ch. 6.

The rest of this lesson develops a course-authored design test. It is not a description of either product’s complete architecture or a claim that its institutional arrangements already exist.

Follow the Authorization, Not Just the Signature

The chain starts before a signing key is used and continues after a device refuses work.

The issuer signs tokens; it need not be the body legally empowered to authorize a run. A manufacturer could operate the signing service for an independent licensing authority. That division only works if the manufacturer cannot silently grant extra permissions—or if the regime explicitly accepts and audits that power.

An enforcement component is the part of the system that permits or blocks the relevant operations. It might live on the chip or elsewhere. We compare those placements in 2.1.6. Here, assume its location is known and ask what it must enforce.

Consider three translation errors. A ten-unit allowance for an entire run becomes ten units on every device. A token issued for one device is accepted by another. Or an already consumed token is accepted again after a restart. All three can increase available computation without changing a signature. The design must preserve the aggregate budget, bind permissions to their intended recipients, and remember consumption across resets.

That is the connection to the previous lessons: identity from 2.1.2, fleet coverage from 2.1.3, and counting conventions and job aggregation from 2.1.4 become dependencies of control—not problems that licensing solves on its own.

Define What “Stop” Means

Throttling reduces a rate or capability. Suspension stops specified activity pending a condition or decision. Revocation withdraws an authorization or trust in a credential. These can interact, but they are not interchangeable.

A slower device may still complete the same work if given enough time. A finite compute allowance limits a quantity; a rate limit alone does not. If throttled work remains possible, account for it explicitly rather than treating the device as disabled.

Suspending a whole accelerator also need not be equivalent to stopping a prohibited run. It can interrupt permitted inference, another tenant’s work, or processes needed to preserve execution records. Conversely, stopping one device may leave the run active elsewhere.

The rule should therefore name the controlled activity and the permitted stopping procedure. Does the system reject new jobs, finish an in-progress operation, save a checkpoint, or halt immediately? Any computation allowed during shutdown belongs in the accounting. “Graceful shutdown” cannot be an unmetered extension that an operator can repeatedly invoke.

Do not assume the hardware can separate training from inference sufficiently well to implement a narrowly targeted suspension. That is precisely the measurement question left open in 2.1.4. A design may have to choose a coarser restriction, with a correspondingly larger burden on permitted use.

Offline Operation Changes the Reach of a Decision

Withdrawing legal permission and changing a remote device’s behavior are two separate events. An offline device cannot react to a new revocation message it has not received.

An allowance can instead run out locally. But a remaining quantity of compute is not a deadline. If an operator pauses the device, the unused allowance may remain available later. Calendar expiry adds a time condition only if the component can reliably determine time and resist attempts to restore an earlier state.

For a proposed regime, ask separately:

• How much additional work can already accepted permissions enable?
• How long can that permission remain usable?
• Which path, if any, delivers a new restriction earlier?
• Can unused tokens, emergency allowances, or other devices expand the bound?

Shorter renewal intervals can reduce some exposure, but also make availability more dependent on renewal infrastructure. A server outage, an intentional blockade of communications, and an operator’s refusal to connect can look similar at the device boundary. The local response needs to be defined without assuming that the device knows which explanation is true.

One design allows bounded continued operation during a communications failure. Another refuses further covered work when permission cannot be refreshed. Neither is “safe” without specifying the harm being prevented: unauthorized computation, disruption of permitted services, or both. The exercise below makes that choice concrete.

Who Controls the Controller?

An attacker need not bypass a meter if they can obtain tokens the meter accepts. A dishonest official need not compromise a key if their office already controls issuance. Technical security and lawful use of authority are different requirements.

Write down control of at least four functions: issuing permissions, suspending them, updating enforcement software, and recovering the system after compromise. Updating software can change what is counted or accepted. A recovery credential that bypasses ordinary checks can become the most powerful credential in the design.

For each function, identify both the legal decision-maker and the actor technically able to make it happen. Then ask whether the arrangement remains acceptable if that actor is negligent, coerced, or politically opposed to the affected operator or state.

One possible safeguard is requiring two independently controlled approvals for a particularly broad action. But two signatures from services administered by the same organization may add little independence. Requiring agreement from everyone can create a different failure: one participant can block urgent action. The design needs explicit choices about ordinary issuance, emergency restrictions, review, and recovery—not the same voting rule applied indiscriminately.

Procedural safeguards are part of compute-governance design, not an afterthought. Sastry and colleagues explicitly discuss limits on the scope of controls and information demands, alongside oversight and review. The following requirements apply that concern to our hypothetical licensing system; they are recommendations for this course scenario, not a statement of existing legal entitlements.

Sastry et al., Computing Power and the Governance of Artificial Intelligence, §5.B.

A suspension procedure should specify the evidentiary threshold, authorized decision-maker, scope, reasons recorded, review deadline, and route to restoration. A provisional restriction is not a final finding of violation. If sensitive evidence cannot be disclosed publicly, the procedure still needs a credible reviewer who can examine it.

Restoration must also be operational. Who can issue replacement permission? What if the original signing key was stolen? A successful appeal cannot safely mean “start trusting the stolen key again.” The system needs a way to install a replacement trust configuration, invalidate obsolete permissions where necessary, and reconcile the remaining budget without granting it twice.

NIST’s firmware-resiliency guidance treats protection, detection, and recovery as complementary functions. It supports asking for a recovery design; it does not certify a particular licensing system or settle who should control recovery.

Regenscheid, Platform Firmware Resiliency Guidelines, NIST SP 800-193, abstract.

Exceptions and Equipment Outside the Control Boundary

An emergency exception should describe an activity, not just a favored operator. Specify its devices, allowable work, budget, duration, approving authority, and subsequent review. If a special allowance is intended only for permitted inference, the design needs a credible way to restrict it to that use. An emergency label is not a workload classifier.

Exceptions also affect the quantitative promise. If a nominal ten-unit cap has an additional five-unit emergency allowance, a claim of “at most ten units” is wrong unless it explicitly excludes that separately authorized work. Recovery operations and shutdown work need the same attention.

Older or otherwise uncovered equipment remains the completeness problem from 2.1.3. Installing a license service does not give a chip a protected enforcement path it never had. An external control may be possible, but requires its own bypass analysis. A transition plan should state which hardware is covered, what restrictions or alternative evidence apply elsewhere, and how migration is verified.

Return briefly to the Chip Security Act exercise: a location check could inform a decision to issue or renew a token. It does not itself confer authority to disable a chip, and an unanswered location challenge does not prove smuggling. Treat location verification, the legal consequences of missing evidence, and a proposed control mechanism as distinct choices. This lesson does not claim that the bill requires the control design developed here.

Exercise — The Authority Has Revoked Permission. What Has Stopped?

This is a hypothetical extension of the course’s pause case, not an NVIDIA or RAND implementation. It does not resolve the historical uncertainty about job J in 2.1.4. The authority is now considering a new, separately authorized activity.

Rule and Evidence Packet

An evaluation permit authorizes ten further compute units in total across four registered devices, A–D. Counted units use the agreement’s convention; no unit conversion is needed. The permit prohibits use outside the specified evaluation. The issuer is supposed to translate the aggregate permission into device allowances.

At 12:00, the authority lawfully suspends that permission with immediate effect while reviewing a concern. The concern is not yet a finding of misconduct. At the same moment, the renewal service becomes unreachable from the facility. For this exercise, assume:

The program director proposes this announcement:

“Permission was revoked at noon, so the evaluation stopped at noon. In any event, hardware licensing limits any further work to ten units and guarantees that all four devices will be disabled by 17:00. If our decision was wrong, restoring the issuer’s key will make the operator whole.”

Questions

Carry Forward

Keep three sentences in your notebook:

• This mechanism can restrict [specified activity] on [covered equipment], subject to [security and coverage assumptions].
• After permission is withdrawn, already accepted allowances can still enable [quantity and/or duration, or an acknowledged unknown].
• [Named authorities] can issue, suspend, review, update, and restore permissions; the safeguards against misuse are [specified checks].

Licensing turns a permission into a technical constraint only where the enforcement path holds. It does not decide whether the permission is legitimate, prove how the compute was used, or reveal equipment outside that path. In 2.1.6, we ask where this enforcement and evidence machinery should live—and which actors each placement requires us to trust.