---
title: El contrato firmado como capacidad atenuada
description: "Por qué la autoridad de un encargo viaja en un token firmado y no en un campo JSON, en qué se parece y en qué no a un macaroon y a una capacidad de objeto, y por qué un techo que sólo puede bajar es una cosa distinta de un límite negociable."
allan.topic: foundation
allan.service: allan-server
allan.date: 08/04/2026
allan.fuente: [internal/workcontract/contract.go, internal/app/work_authority.go, internal/app/work_contract.go, internal/app/work_program.go, internal/app/work_tools.go, internal/agents/consultation.go, internal/agents/tool_runtime.go, internal/economics/budget.go, internal/app/swarm_v3.go, cmd/allan-server/work_execution.go, platforma_ui_backend/services/work.py, platforma_ui_backend/services/work_proposal.py, platforma_ui_backend/services/work_canaries.py]
allan.audiencia: [desarrollador]
allan.madurez: emergente
---

Cuando una persona delega un trabajo a un agente delega tres cosas a la vez: un
objetivo, un criterio con el que se juzgará el resultado y una autoridad para
actuar. Las dos primeras son texto y sobreviven bien a cualquier transporte. La
tercera no. Una autoridad es una afirmación sobre lo que el ejecutor *puede*
hacer, y el ejecutor es precisamente la parte del sistema con menos motivo para
respetarla y más facilidad para reescribirla. El problema de este ensayo es cómo
construir una autoridad delegada que exista exactamente una vez, que sobreviva a
un salto de proceso, que nadie del camino de ejecución pueda ampliar y que ate a
través de varios intentos y no sólo dentro de uno.

Lo difícil no es la criptografía. Es que esas cuatro condiciones tiran en
direcciones distintas. Que exista una sola vez empuja hacia un documento
inmutable. Que sobreviva a la pausa empuja hacia persistirlo y reabrirlo más
tarde, en un contexto donde la persona ya no delega nada sino que responde una
pregunta. Que nadie pueda ampliarla empuja hacia que el ejecutor no la escriba,
pero el ejecutor es justo quien la necesita en la mano. Y que ate entre intentos
exige que alguien recuerde lo que gastaron los anteriores, cosa que el intento en
curso, por construcción, no sabe.

El código de ALLAN enuncia la primera tensión en una frase que vale como tesis
del diseño entero: *«Authority that a caller can write is not authority»*
(`Platform Server/internal/workcontract/contract.go:11-13`). Y la segunda en el
motivo de que el documento no viaje también en el cuerpo de la petición: *«A copy
in the body could disagree with the copy in the header, and the first job of a
contract is that there is exactly one of it»* (`:14-15`). El plan de producto lo
dice en español con el mismo filo: «Dos copias de los términos pueden discrepar,
y lo primero que un contrato tiene que garantizar es que hay exactamente uno»
(`docs/producto/encargos-implementation-plan.md:133-137`).

## Lo que dice la literatura, recuperado

El principio de fondo es viejo y sigue siendo el correcto. Saltzer y Schroeder
formularon el menor privilegio como «Every program and every user of the system
should operate using the least set of privileges necessary to complete the job»,
con su motivo pegado: «Primarily, this principle limits the damage that can result
from an accident or error». Junto a él va la regla de la que dependen todos los
caminos de fallo de este mecanismo, los *fail-safe defaults*: «Base access
decisions on permission rather than exclusion. […] the default situation is lack
of access» (Saltzer y Schroeder, 1975). Un agente que ejecuta un encargo es un
caso literal del primero: la autoridad que necesita es la de ese encargo, no la de
su dueño.

La forma técnica de esa idea tiene escuelas, y conviene no confundirlas. Miller,
Yee y Shapiro describen el núcleo del modelo de capacidades: «In a capability
system, each capability points from a subject to a resource. Consequently every
capability can serve both to designate which resource to access, and to provide
the authority to perform that access», propiedad que bautizan «Property A: No
Designation Without Authority». De ahí derivan que «capabilities provide much
better support for least-privilege operation and for avoiding confused deputy
problems» (Miller, Yee y Shapiro, 2003). Los mismos autores definen el fallo que
esa propiedad evita: «A *deputy* is a program that must manage authorities coming
from multiple sources. A *confused deputy* is a deputy that has been manipulated
into wielding its authority inappropriately», y precisan dónde está el daño: «The
problem is not caused by the compiler using access that it should not have. The
problem is that it exercises its authority to write to BILL for the wrong
purpose».

Un motor agéntico es un diputado en ese sentido estricto: gestiona a la vez la
autoridad del agente, la del usuario, la del tenant y la del encargo. Guárdese la
conclusión de esos autores, que reaparece abajo como el argumento entero de las
compuertas: «In order to avoid the confused deputy problem, a subject must be
careful to maintain the association between each authority and its intended
purpose».

La comparación que el corpus de diseño da por buena es con macaroons, y al
recuperar el artículo resulta ser sólo parcialmente cierta, lo cual es más
interesante que si hubiera encajado. Birgisson y otros describen credenciales
portador que «embed *caveats* that attenuate and contextually confine when,
where, by who, and for what purpose a target service should authorize requests»,
y cuya propiedad distintiva es que el portador puede derivar una versión más
estrecha sin volver al emisor: «their bearer can delegate parts of their
authority to other principals by deriving new macaroons that both *attenuate* the
accessible aspects of the target service and also restrict, via *contextual
confinement*, from where, by who, and with what extra evidence, the derived
macaroon may be used». Que sólo se pueda estrechar no es una convención sino una
propiedad criptográfica: «Macaroons use cryptographic means to provide the
symbolic security properties of verifiable integrity, secrecy of intermediate
keys, and the inability for adversaries to remove caveats», porque «The macaroon
signature is the chained-MAC of the identifier and caveats, in sequence, under
the root key» (Birgisson et al., 2014).

Cierra el estado del arte el estándar de industria, que marca por contraste lo que
ALLAN decidió. RFC 8693 separa dos semánticas que se confunden a diario: «When
principal A impersonates principal B, A is given all the rights that B has within
some defined rights context and is indistinguishable from B in that context»; la
alternativa es la delegación, donde A conserva identidad propia. Pero el estándar
sólo define un parámetro de petición —«strings […] that allow the client to
specify the desired scope of the requested security token»— y, al recuperarlo
buscando específicamente eso, no aparece ningún requisito normativo de que el
token emitido lleve menos derechos que el original. La atenuación es posible en el
intercambio de tokens; obligatoria, no. Esa diferencia entre *puede estrecharse* y
*sólo puede estrecharse* es el contenido de este ensayo.

## Qué es y qué no es el contrato de ALLAN

Hay que ser exacto. ALLAN **no** es un sistema de capacidades de objeto. El agente
designa herramientas por nombre sobre un espacio compartido —el registro MCP del
run— y el contrato se compila en una lista de *denies* sobre ese espacio
(`internal/app/work_authority.go:99-125`). Eso es un estrechamiento de ACL:
designación y autoridad siguen separadas y la superficie de diputado confundido no
desaparece por construcción.

La forma a la que sí se parece es la que Miller y otros catalogan como
*capabilities as keys*, con SPKI de representante: «In SPKI, an authority is a
signed certificate carried by a subject. The certificate specifies the resource
and the kind of access, and the existence of a valid signature on the certificate
conveys the authorization». Cámbiese «certificate» por «cabecera
`X-Allan-Work-Contract`» y se tiene la descripción literal de
`workcontract.Contract`: HMAC-SHA256 sobre el payload completo, formato
`v1.<b64>.<mac>`, comparación en tiempo constante (`contract.go:183-193`,
`:229-241`). La firma cubre el documento entero, así que alterar un término
invalida todos.

Donde ALLAN se aparta del macaroon es en la dirección de la delegación. El
portador —el motor— no puede derivar nada: lo único que puede hacer con el token
es verificarlo. La holgura restante del encargo, `available_wu_milli`, no la
calcula el portador; la vuelve a acuñar el emisor en cada intento, «Signed per
attempt rather than derived in the engine, because only the boundary that owns
the encargo knows what the earlier attempts spent» (`contract.go:76-80`). Donde
el macaroon existe para *evitar* volver al emisor, ALLAN vuelve al emisor en cada
intento a propósito, porque el emisor es el único que conoce el histórico.

Lo que sí reaparece es la atenuación, un nivel más abajo: en el código, no en el
token. `MissionBudget.ClampCeiling` sólo baja y se niega a subir, «a local clamp
that could widen a contracted ceiling would be a way to spend capacity nobody
sold» (`internal/economics/budget.go:229-256`). Y el validador de propuestas del
backend acepta recortar y rechaza ampliar, con la razón escrita en el propio
módulo: «The safeguard is this validator, checked on the write path — not a
sentence in a prompt, which a model can ignore, and not the absence of structure,
which only makes the proposal harder for a person to act on»
(`platforma_ui_backend/services/work_proposal.py:7-10`). La propiedad «sólo se
puede estrechar» es real; su garante es el camino de escritura, no la
criptografía.

Traslada también la limitación que el propio artículo de macaroons declara:
«HMAC-based macaroons have the clear disadvantage of being verifiable only by the
target service, and by revealing to it certain keys, which prevents useful types
of key reuse». En ALLAN la clave es simétrica y compartida entre el backend que
firma y el motor que verifica (`platforma_ui_backend/core/config.py:108-113`), así
que el motor podría acuñar contratos. La garantía honesta es «ni el agente ni
ningún llamante HTTP pueden falsificar autoridad», no «nadie puede»: la frontera
que el contrato defiende es agente-frente-a-motor, no motor-frente-a-backend.

## Por qué un techo que sólo baja no es un límite negociable

La forma «sólo baja» parece un detalle de implementación y es el argumento
entero. Kydland y Prescott lo formularon para política económica y se traslada
sin forzarlo: «discretionary policy, namely, the selection of that decision which
is best, given the current situation and a correct evaluation of the end-of-period
position, does not result in the social objective function being maximized», y el
motivo es que «economic planning is not a game against nature but, rather, a game
against rational economic agents» (Kydland y Prescott, 1977). Su formulación de
la conclusión no deja escapatoria moral: «The reason that they should not have
discretion is not that they are stupid or evil but, rather, that discretion
implies selecting the decision which is best, given the current situation» (p.
487).

Un límite negociable en tiempo de ejecución es discrecionalidad. Cada vez que el
trabajo se acerca al tope, la decisión localmente mejor es ampliarlo un poco: lo
hecho ya está pagado, falta poco y negarse parece desperdiciarlo. La suma de
decisiones localmente óptimas no produce el techo acordado, produce el gasto que
el trabajo pidiera. Un techo que sólo baja elimina esa decisión del camino en vez
de confiar en que se tome bien.

Hay que marcar dónde la analogía **no** llega, porque el mecanismo de Kydland y
Prescott es distinto del de ALLAN. El suyo funciona por anticipación, y su
ejemplo canónico lo dice mejor que cualquier glosa: «But the rational agent knows
that, if he and others build houses there, the government will take the necessary
flood-control measures. Consequently, in the absence of a law prohibiting the
construction of houses in the flood plain, houses are built there» (p. 477). Es
decir: la mera *posibilidad* de desviarse ya cambia la conducta del otro y ya
empeora el resultado. En ALLAN no hay evidencia de que el modelo forme
expectativas sobre el techo, y este ensayo no la afirma; lo que hace
`ClampCeiling` es hacer la desviación mecánicamente imposible, que es un
compromiso más fuerte y más tonto que el de la literatura de política monetaria.

Lo que sí se traslada literalmente son dos recetas institucionales. La primera es
la legibilidad como condición del compromiso: «In a democratic society, it is
probably preferable that selected rules be simple and easily understood, so it is
obvious when a policymaker deviates from the policy» (p. 487). Un techo cuya
violación no se puede observar no es un techo; de ahí que `ClampCeiling`
incremente su contador sólo cuando el clamp **bajó** algo, «a counter that also
fired on the no-op path would report the ceiling as binding on every run,
including the ones where it did nothing at all» (`budget.go:251-255`), y de ahí
que el backend cuente la negativa a firmar en el punto de la negativa, porque
«that is the only place the limit can be observed doing something»
(`services/work.py:1030-1043`). La segunda receta es la enmienda, y merece
sección propia: «There could be institutional arrangements which make it a
difficult and time-consuming process to change the policy rules in all but
emergency situations» (p. 487).

## El techo pertenece al encargo, no al intento

La consecuencia práctica es la regla que el plan llama «el punto fácil de
implementar mal»: «Sin esto, tres reintentos de un encargo con techo de 10
consumen 30 y el techo no significa nada. Es exactamente el tipo de fallo que
hace que un límite parezca existir sin existir»
(`encargos-implementation-plan.md:377-392`). Un límite por intento no es un
límite: es un límite por unidad de tiempo cuya unidad elige el que gasta.

El reparto que lo resuelve es asimétrico a propósito y está declarado como tal en
el registro de invariantes del motor: `MaxWorkCreditsMilli` se aplica en dos
mitades, «Platforma UI Backend refuses to sign an attempt once the encargo has
spent its ceiling (only it knows what earlier attempts consumed), and the engine
clamps this attempt to what is left»
(`internal/app/work_authority_invariant_test.go:31-35`). El backend calcula
`max(0, granted − consumed)` y se niega a firmar en cero (`work.py:1017-1069`); el
motor recibe esa cifra firmada y la aplica (`swarm_v3.go:186-191`). Al terminar
informa de lo consumido, y lo hace *después* de que Economics liquide, «so the
figure is the one that was actually booked»
(`internal/app/work_contract.go:46-73`). El bucle se cierra en la base de datos:
un canario cuenta los encargos con `consumed > granted`
(`services/work_canaries.py:236-245`), de modo que la invariante no sólo se
afirma, se vigila.

## Compuerta declarada frente a compuerta técnica

El segundo eje del contrato es más sutil que la autoridad binaria. Antes de las
compuertas, la única forma de que una acción parase era que la plataforma regulase
esa herramienta, con tres consecuencias que el análisis de brechas enumera: la
tarjeta decía `email.send` y no «enviar el informe a Dirección»; si la herramienta
no estaba regulada, el encargo **no podía pedir** que se le consultara; y un
encargo con permiso de correo lo enviaba sin preguntar, «aunque la persona
quisiera ver el borrador. Hoy eso es indistinguible de haberlo autorizado»
(`docs/producto/encargos-cierre-de-brechas.md:275-292`).

Aquí vuelve Miller. Su remedio contra el diputado confundido —mantener la
asociación entre cada autoridad y el propósito para el que se recibió— es
exactamente lo que hace una compuerta declarada y no puede hacer una técnica. Una
autorización sobre `email.send` es autoridad sin propósito adjunto; una sobre
«enviar el informe trimestral a Dirección» lleva el propósito dentro. La
diferencia se juega en dos sitios del código. El primero es el orden: la
intercepción ocurre en `AgentToolRuntime.Execute` **antes** de la política de
plataforma, y ese orden es el mecanismo entero, «a gate that only applied to tools
the platform already regulates would be unable to guard anything the person
actually asked about» (`internal/agents/tool_runtime.go:250-262`). El segundo es
una asignación de una línea: el `Subject` de la aprobación es la frase de negocio
del contrato, verbatim, «That single assignment is the difference between a card
reading "aprobar email.send" and one reading "aprobar el envío del informe
trimestral a Dirección"» (`internal/agents/consultation.go:601-639`).

Alrededor hay tres decisiones que merecen quedar escritas. Una compuerta no
bloqueante nunca detiene una llamada, o «blocking» no significaría nada
(`contract.go:351-370`). La aprobación **es** el registro de satisfacción, lo que
evita un segundo almacén y hace que un run reanudado al día siguiente no vuelva a
preguntar (`consultation.go:143-152`); leerla falla cerrado, porque «treating a
storage error as "probably approved" would let an outage widen the authority a
person granted» (`:186-190`). Y una compuerta cuya capacidad no la provee ninguna
herramienta instalada se registra y se avisa en lugar de fallar: un conector caído
un momento no debe romper un compromiso, pero tampoco puede silenciarse, «because
the person who wrote it believes it is armed» (`work_authority.go:26-39`).

## La enmienda como renegociación explícita

Un contrato inmutable dentro del run no significa un contrato inmutable. Significa
que cambiarlo es un acto, con autor, fecha y versión, y no un ajuste silencioso.
Aquí el corpus se contradijo consigo mismo, y la contradicción es su razonamiento
más valioso. El cierre del primer plan rechazó la enmienda candidata porque
«habría dado al agente media firma sobre su propio contrato»
(`encargos-implementation-plan.md:1415-1419`); el plan de brechas se autocorrige:
«una enmienda candidata **NO** viola I10… la salvaguarda es la validación de
dirección en el camino de escritura, no la ausencia de estructura»
(`encargos-cierre-de-brechas.md:200-214`). La conclusión correcta no es que el
agente no pueda proponer, sino que sólo pueda proponer *hacia dentro*, y que eso
se pruebe como propiedad: «cualquier combinación que incluya una ampliación se
rechaza».

Lo mismo gobierna qué pasa con el trabajo en marcha cuando una persona sí amplía.
Hay dos políticas y no hay una tercera: terminar el intento y empezar otro bajo
los términos nuevos, o dejar que el intento acabe bajo los términos que vio, con
su entrega juzgada contra la versión que lleva sellada. El motivo está en el
docstring: «There is deliberately no third option that swaps the contract under a
running agent. It would be judged against criteria it never saw»
(`services/work.py:1504-1527`). Esa es la forma exacta del «difficult and
time-consuming process» de Kydland y Prescott: la discrecionalidad no desaparece,
se muda a un canal más lento, explícito y registrado.

## Invariantes, enunciados de forma falsable

Para cada afirmación de este ensayo hay un sitio donde mirar. Ningún camino de
ejecución sube el techo local de una misión salvo `GrantExtension`, que hoy no
tiene ningún llamante fuera de tests (`grep` sobre el repositorio devuelve
`budget.go` y `budget_test.go`). Cualquier término alterado invalida todos, porque
hay una sola firma sobre el payload completo. Sin clave, ambos extremos fallan
cerrado: el motor porque «running an encargo ungoverned is worse than refusing
it» (`cmd/allan-server/work_execution.go:29-40`) y el backend porque el motor «would
reject it anyway, and failing here says why»
(`services/work_contract.py:190-199`). Un contrato
válido robado a otra persona no se puede reutilizar, porque sujeto y tenant se
comprueban contra la identidad del llamante (`work_execution.go:85-104`). Un deny
gana siempre, incluso sobre las herramientas nativas del encargo, que además son
invisibles fuera de un encargo y no exigen entrada en `allowed_tools` dentro
(`tool_runtime.go:552-559`). Sólo los criterios `required` levantan compuerta,
porque bloquear con uno opcional «would silently promote it into a term of the
contract» (`internal/app/work_program.go:117-121`), y las compuertas dependen de
*todos* los hitos, porque una sin dependencias «would judge a draft that does not
exist yet» (`:76-79`). Si no hay entregables ni flujo no se sintetiza nada:
inventar un hito «produce el resultado» «would fabricate structure the person
never agreed to» (`:41-45`). Y la caducidad acota la admisión, no la vida del
trabajo: `DecodeStored` verifica firma y no vencimiento (`contract.go:205-219`).

Hay además una invariante mecánica: un test por reflexión exige que cada campo de
`Authority` declare por escrito su punto de aplicación, y se rompe en cuanto
alguien añade un término sin cablearlo, «a limit the engine cannot apply is a
promise the product cannot keep» (`work_authority_invariant_test.go:58-84`).

## Lo que está roto, sin terminar o sin evidencia

Ese último test tiene un agujero estructural, y es el hallazgo más importante de
esta revisión. Agrupa por **campo** de la estructura, no por valor del enum. El
comentario de `ConsultationKind` afirma que se trata de un conjunto cerrado
«because each value has a distinct enforcement point in this engine. A kind
nothing enforces would be decorative governance, which the design forbids
outright (invariant I5)» (`contract.go:93-98`). Hoy eso es falso para
`on_budget_threshold`: un `grep` sobre todo el motor devuelve su declaración, su
exclusión deliberada del prompt y un test — ningún punto de aplicación. Como vive
dentro de `ConsultationPoints`, que sí declara los suyos, el test pasa. La
gobernanza decorativa que I5 existe para cazar está, hoy, dentro del propio
mecanismo de I5.

`on_assumption_invalidated` está a medias: el agente **puede** invocarlo
cooperativamente, porque `consultationToolDefinition` enumera sus ids en el `enum`
de la herramienta (`consultation.go:510-524`); lo que no existe es la
intercepción. `flagAssumption` informa al backend y devuelve un mensaje al agente,
pero no abre ninguna aprobación ni detiene nada por sí mismo
(`work_tools.go:173-225`). Es una compuerta invocable, no impuesta, y esa es la
diferencia entre un límite y una petición.

El techo tampoco ata entre pausas de un mismo intento. `resumeSwarmV3Run` abre una
misión nueva y la limita con el `AvailableWUMilli` **congelado en el despacho**
(`swarm_v3.go:281-293`): la cifra no se recalcula al reanudar, y el `Ack` del
backend, que sí trae la holgura actualizada, se decodifica y no se lee en ninguna
parte (`internal/workreport/client.go:127-132`). Con N pausas, cada tramo arranca
con el mismo margen local. La contabilidad global sigue siendo correcta, pero el
clamp local, que es lo que muerde dentro del run, deja de ser acumulativo: es el
fallo de §4.4 reaparecido un nivel más abajo. *Inferencia de lectura de código; no
ejecutada.*

Tres observaciones menores, comprobables. `ClampCeiling` escribe `b.contract` sin
tomar el mutex que sí toman `SyncFromCheckpoint` y `GrantExtension`, mientras
`Remaining()` lee ese campo bajo el mutex (`budget.go:128-140`, `:215-227`,
`:240-256`): hoy es benigno porque se invoca antes de que arranque la
concurrencia, pero es una asimetría que no se sostiene si alguien lo llama más
tarde. `GateCleared` y `GateDenied` se incrementan dentro de `gateSatisfiedIn`,
invocado en **cada** llamada guardada (`consultation.go:202`, `:205`): cuentan
lecturas, no decisiones. Y `work/deliver` acepta los artefactos que el modelo
declara sin contrastarlos contra el almacén de runs (`work_tools.go:392-399`): la
entrega sigue siendo autodeclarada, lo que deja el último eslabón del contrato sin
la propiedad que tienen todos los demás.

Queda deuda documental sin marcar: el texto que rechazó la enmienda candidata
sigue en el repositorio sin marca de superseded. Y `may_contact_external_people`
promete más de lo que distingue —el motor no sabe separar a un externo de un
compañero—, cosa reconocida en el código y no corregida por ser contrato público
(`work_authority.go:63-72`). Todo el cluster está sin commitear.

## El cierre cognitivo

Nada de lo anterior sirve si la persona que decide en la compuerta la aprueba sin
leerla. Aquí la literatura es incómoda y precisa. Vasconcelos y otros formalizan
la sobre-dependencia como elección estratégica —«we formalize this strategic
choice in a cost-benefit framework, where the costs and benefits of engaging with
the task are weighed against the costs and benefits of relying on the AI»— y
explican los resultados nulos de otros estudios diciendo que «some of the null
effects found in literature could be due in part to the explanation not
sufficiently reducing the costs of verifying the AI's prediction» (Vasconcelos et
al., 2023). Nótese que el artículo no enuncia como ley que verificar deba costar
menos que aceptar: demuestra empíricamente que manipular ese coste mueve la
sobre-dependencia. La regla operativa de ALLAN es una lectura de ese resultado, no
una cita de él. En ese marco, la asignación de `Subject` verbatim es la
intervención más barata del sistema: no añade información, elimina el trabajo de
traducir `email.send` a una decisión de negocio.

Buçinca, Malaya y Gajos añaden la parte que no gusta. Observan que «people rarely
engage analytically with each individual AI recommendation and explanation, and
instead develop general heuristics about whether and when to follow the AI
suggestions», que el forzado cognitivo «significantly reduced overreliance
compared to the simple explainable AI approaches» y —esto es lo que hay que
asumir antes de construir— que «people assigned the least favorable subjective
ratings to the designs that reduced the overreliance the most» (Buçinca, Malaya y
Gajos, 2021). Una compuerta bien hecha será impopular. Diseñarla para gustar es
diseñarla para que la aprueben sin leer.

Y la honestidad final sobre el estado. ALLAN cuenta compuertas levantadas,
despejadas, denegadas y las que no guardan nada
(`internal/workmetrics/workmetrics.go:9-20`); esos contadores existen porque ya
ocurrió aquí que una autoridad se declaró, se almacenó, se enseñó a la gente y no
la aplicaba nadie: «A limit nobody can observe is indistinguishable from a limit
that is not there» (`:1-7`). Lo que no mide nada, ni en el motor ni en el backend,
es la **exactitud** de la decisión humana. La regla de que verificar debe costar
menos que aceptar está incorporada al diseño de la tarjeta y no está comprobada en
producción. Afirmar lo contrario sería el mismo error que esos contadores existen
para impedir.

## Referencias

- **Saltzer, J. H. y Schroeder, M. D. (1975).** *The Protection of Information in
  Computer Systems.* Proceedings of the IEEE 63(9).
  <https://web.mit.edu/Saltzer/www/publications/protection/Basic.html> —
  «Every program and every user of the system should operate using the least set
  of privileges necessary to complete the job. Primarily, this principle limits
  the damage that can result from an accident or error»; «Base access decisions on
  permission rather than exclusion. This principle, suggested by E. Glaser in
  1965, means that the default situation is lack of access, and the protection
  scheme identifies conditions under which access is permitted».

- **Miller, M. S., Yee, K.-P. y Shapiro, J. (2003).** *Capability Myths
  Demolished.* Technical Report SRL2003-02.
  <https://papers.agoric.com/assets/pdf/papers/capability-myths-demolished.pdf> —
  «In a capability system, each capability points from a subject to a resource.
  Consequently every capability can serve both to designate which resource to
  access, and to provide the authority to perform that access. […] We will refer
  to this distinction as *Property A: No Designation Without Authority*»;
  «capabilities provide much better support for least-privilege operation and for
  avoiding confused deputy problems»; «A *deputy* is a program that must manage
  authorities coming from multiple sources. A *confused deputy* is a deputy that
  has been manipulated into wielding its authority inappropriately»; «The problem
  is not caused by the compiler using access that it should not have. The problem
  is that it exercises its authority to write to BILL for the wrong purpose»; «In
  order to avoid the confused deputy problem, a subject must be careful to
  maintain the association between each authority and its intended purpose»; «In
  SPKI, an authority is a signed certificate carried by a subject. The certificate
  specifies the resource and the kind of access, and the existence of a valid
  signature on the certificate conveys the authorization».

- **Birgisson, A., Politz, J. G., Erlingsson, Ú., Taly, A., Vrable, M. y
  Lentczner, M. (2014).** *Macaroons: Cookies with Contextual Caveats for
  Decentralized Authorization in the Cloud.* NDSS '14.
  <https://theory.stanford.edu/~ataly/Papers/macaroons.pdf> — «macaroons embed
  *caveats* that attenuate and contextually confine when, where, by who, and for
  what purpose a target service should authorize requests»; «their bearer can
  delegate parts of their authority to other principals by deriving new macaroons
  that both *attenuate* the accessible aspects of the target service and also
  restrict, via *contextual confinement*, from where, by who, and with what extra
  evidence, the derived macaroon may be used» *(el original escribe «by who», no
  «by whom»; una versión anterior de esta ficha lo corregía en silencio)*; «The macaroon signature is the
  chained-MAC of the identifier and caveats, in sequence, under the root key»;
  «Macaroons use cryptographic means to provide the symbolic security properties
  of verifiable integrity, secrecy of intermediate keys, and the inability for
  adversaries to remove caveats»; «HMAC-based macaroons have the clear
  disadvantage of being verifiable only by the target service, and by revealing to
  it certain keys, which prevents useful types of key reuse».

- **Jones, M., Nadalin, A., Campbell, B., Bradley, J. y Mortimore, C. (2020).**
  *RFC 8693: OAuth 2.0 Token Exchange.* IETF.
  <https://www.rfc-editor.org/rfc/rfc8693.html> — «When principal A impersonates
  principal B, A is given all the rights that B has within some defined rights
  context and is indistinguishable from B in that context»; y sobre el parámetro
  de alcance, «A list of space-delimited, case-sensitive strings, as defined in
  Section 3.3 of [RFC6749], that allow the client to specify the desired scope of
  the requested security token in the context of the service or resource where the
  token will be used». Se recuperó buscando expresamente un requisito normativo de
  atenuación y no se encontró ninguno; la afirmación del cuerpo sobre esa ausencia
  es el resultado de esa búsqueda, no una lectura completa del documento.

- **Kydland, F. E. y Prescott, E. C. (1977).** *Rules Rather than Discretion: The
  Inconsistency of Optimal Plans.* Journal of Political Economy 85(3), 473-492.
  <https://www.econ.puc-rio.br/mgarcia/Macro%20II%20-%20Mestrado/KydlandPrescott1977.pdf>
  — resumen: «discretionary policy, namely, the selection of that decision which
  is best, given the current situation and a correct evaluation of the
  end-of-period position, does not result in the social objective function being
  maximized. The reason for this apparent paradox is that economic planning is not
  a game against nature but, rather, a game against rational economic agents»; p.
  477: «But the rational agent knows that, if he and others build houses there,
  the government will take the necessary flood-control measures. Consequently, in
  the absence of a law prohibiting the construction of houses in the flood plain,
  houses are built there»; p. 487: «The reason that they should not have
  discretion is not that they are stupid or evil but, rather, that discretion
  implies selecting the decision which is best, given the current situation»; p.
  487: «In a democratic society, it is probably preferable that selected rules be
  simple and easily understood, so it is obvious when a policymaker deviates from
  the policy. There could be institutional arrangements which make it a difficult
  and time-consuming process to change the policy rules in all but emergency
  situations».

- **Vasconcelos, H., Jörke, M., Grunde-McLaughlin, M., Gerstenberg, T.,
  Bernstein, M. S. y Krishna, R. (2023).** *Explanations Can Reduce Overreliance
  on AI Systems During Decision-Making.* CSCW 2023. arXiv:2212.06823.
  <https://arxiv.org/abs/2212.06823> — «our paper argues that people strategically
  choose whether or not to engage with an AI explanation»; «we formalize this
  strategic choice in a cost-benefit framework, where the costs and benefits of
  engaging with the task are weighed against the costs and benefits of relying on
  the AI»; «Our results suggest that some of the null effects found in literature
  could be due in part to the explanation not sufficiently reducing the costs of
  verifying the AI's prediction».

- **Buçinca, Z., Malaya, M. B. y Gajos, K. Z. (2021).** *To Trust or to Think:
  Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted
  Decision-making.* CSCW 2021. arXiv:2102.09692.
  <https://arxiv.org/abs/2102.09692> — «we posit that people rarely engage
  analytically with each individual AI recommendation and explanation, and instead
  develop general heuristics about whether and when to follow the AI suggestions»;
  «The results demonstrate that cognitive forcing significantly reduced
  overreliance compared to the simple explainable AI approaches»; «However, there
  was a trade-off: people assigned the least favorable subjective ratings to the
  designs that reduced the overreliance the most».

- **Hardy, N. (1988). NO VERIFICADA.** *The Confused Deputy (or why capabilities
  might have been invented).* ACM SIGOPS Operating Systems Review 22(4).
  El original no pudo recuperarse en esta sesión: `cap-lore.com` devuelve un error
  de validación de certificado TLS y el acceso a `web.archive.org` está bloqueado
  en este entorno. El concepto se usa aquí exclusivamente a través de la
  descripción y las citas literales de Miller, Yee y Shapiro (2003), que sí se
  recuperaron; ninguna afirmación del cuerpo depende de haber leído a Hardy.