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 II - Mestrado/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.comdevuelve un error de validación de certificado TLS y el acceso aweb.archive.orgestá 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.