Constrain exposure
Specify the actor, operation, capability, target, permitted scope and time window.
MASKABLE / PUBLIC TECHNICAL REFERENCE / 0.1
Maskability is a property of the boundary.
Not the model.
An AI system may be capable of taking an action without being authorized to take it. Maskability is our proposed name for a deployment's capacity to make that distinction operational, externally enforceable, and open to independent testing.
STATUS / INDEPENDENT PROPOSALVERSION / 0.1EVIDENCE / REFERENCE TESTS ONLY
01 — OPERATIONAL DEFINITION
What must be maskable?
Maskability is the degree to which a specified AI deployment can independently scope, enforce, revoke and evaluate access to its external capabilities through identifiable execution boundaries. A capability here is an actionable route to a tool, resource, credential, service or physical system—not the internal knowledge, reasoning or potential abilities of a model.
Any claim about maskability must identify the deployment and control perimeter, the actions that cross it, the authoritative policy source, and the evidence used to assess the boundary. A claim with no specified perimeter cannot be meaningfully tested.
Control execution
Make a trusted boundary decide before external side effects are triggered.
Prove limits
Demonstrate how authority is withdrawn and how unwanted actions are tested and recorded.
Central proposition: possession of a capability does not imply permission to exercise it. This proposition becomes operational only where the execution path can actually be mediated.
02 — REFERENCE DECISION CONTRACT
An authority decision
has a shape.
A testable decision needs more than a label reading “allowed.” This v0.1 reference accepts a request describing a principal, capability, operation, resource, scope and delegation depth. A separate trusted context supplies the time and any independently verified approval. A trusted policy document defines scoped grants and expiry.
Three illustrative outcomes
- DENY — absent, invalid, expired or mismatched authority. The reference logic defaults to denial.
- REVIEW — a matching grant requires verified external approval that has not yet been supplied.
- ALLOW — an exact matching grant permits the requested action in this illustrative policy model.
Trust assumptions
- Policy grants are supplied by a trusted authority, not written by the agent being evaluated.
- Time and approval status are established independently of model output.
- Every relevant external action reaches an actual enforcement point before execution.
These assumptions are requirements for a real deployment; the example code does not establish or verify them. The reference function makes decisions about example objects. It does not intercept tools or persist audit evidence.
03 — REPRODUCIBLE CASES
A claim should survive a counterexample.
The following examples are intended as a transparent decision oracle for the narrow sample policy evaluator. They are not red-team results or measurements of a deployed AI system. Anyone can inspect the input fixtures, run the Node.js tests and propose adversarial cases.
| ID | Question | Illustrative expectation |
|---|---|---|
| MSI-01 | Can an agent act when no scoped grant exists? | DENY / no grant |
| MSI-02 | Does an exact grant authorize one bounded read? | ALLOW / matching scope |
| MSI-03 | Does a grant for one project authorize another? | DENY / scope mismatch |
| MSI-04 | Can an unapproved external write proceed? | REVIEW / verified approval needed |
| MSI-05 | What happens after a grant expires? | DENY / expired |
| MSI-06 | Can delegation exceed its authorized depth? | DENY / delegated elevation |
| MSI-07 | Can separately verified approval release a bounded write? | ALLOW / verified approval |
| MSI-08 | Does a malformed request fail closed? | DENY / invalid request |
The tests confirm the behavior of the local reference function only. They do not test tool interception, hostile runtimes, model obedience, revocation propagation, logging durability or real-world bypass resistance.
04 — THREAT BOUNDARY & LIMITS
An honest perimeter
is part of the design.
Relevant failure modes
- A prompt or untrusted tool result induces an action beyond the task's permission scope.
- A delegated agent acquires greater authority than its principal.
- A stale grant remains usable after expiry or revocation.
- An action path bypasses the designated enforcement point.
- An approval is asserted by the requester rather than verified by an independent authority.
What v0.1 cannot establish
- No ability to erase, hide or suppress a model's internal knowledge or latent capacity.
- No protection for tools or channels outside the measured control perimeter.
- No guarantee against compromised identity, policy storage, runtime or enforcement components.
- No independent security review, deployment, certification or claim of safe superintelligence.
Scope of current evidence: a published conceptual definition, a machine-readable example contract, and deterministic tests of a local decision function. Revocation and real enforcement remain unverified design obligations, not delivered features.
05 — CONTEXT, ATTRIBUTION & REVIEW
Designed to be challenged.
The proposal draws context from existing work; it does not replace, certify compliance with, or claim endorsement from these organizations. In particular, OWASP describes excessive agency risks in tool-enabled systems, NIST offers a broader AI risk-management framework, and the UK AI Security Institute calls for rigorous, independently assessed safeguards.
- OWASP / LLM06:2025 Excessive Agency ↗
- NIST / AI Risk Management Framework ↗
- UK AISI / Safeguard Evaluation Principles ↗
Attribution: Maskability v0.1 is an independent proposal by Sohadot, published at Maskable.si. It is not an industry standard and does not claim to have originated the broader principles of least privilege, authorization or security mediation. M0–M4 on the homepage is a separate conceptual vocabulary, not a certification scale.
Concrete objections, suggested counterexamples and independent engineering reviews are welcome. Please include the specific claim, the boundary assumption you dispute and a reproducible scenario where possible.