Resumen

  • El primer borrador AAuth Budgets, fechado el 28 de septiembre, permite que un recurso limite lo que consume un agente bajo un token de autorización concreto.
  • La persona puede tener varios tokens vigentes; quien los emite debe reservar su exposición conjunta y no interpretar un saldo desconocido como gasto nulo.

La imagen más intuitiva de un límite es una puerta que se cierra al alcanzar una cifra. El borrador publicado por Dick Hardt obliga a mirar también al pasillo anterior a las puertas. Si un servidor concede dos tokens simultáneos de diez unidades cada uno —cifras hipotéticas—, el recurso puede cerrar ambas puertas exactamente a tiempo y aun así admitir veinte unidades de consumo. Cuando el techo que la persona quería era diez, no falló la comprobación de los tokens: se concedió dos veces el mismo margen.

AAuth Budgets es por ahora un Internet-Draft individual y exploratorio. El documento indica como intención avanzar por Standards Track, pero el Datatracker de la IETF solo registra que existe el borrador y no define una vía RFC. No es una norma ratificada ni una adopción comprobada. La propuesta amplía otro borrador, el protocolo AAuth. El agente solicita una cantidad, el recurso declara la unidad que usa y lo que ofrece, el servidor de la persona y, en su caso, un servidor de acceso pueden reducirla, y el token de autorización contiene lo finalmente concedido. El recurso aplica ese importe; el servidor de la persona no presencia cada solicitud y no divulga en el token el techo global que administra.

El diseño local es más exigente que una notificación posterior. Según el borrador, la suma de consumo comprometido y reservas pendientes de un token no debe superar la cantidad de ese token. Una llamada de inferencia puede generar una salida cuyo coste solo se conoce al terminar. Por eso el recurso tiene que fijar antes un coste máximo finito, reservarlo, ejecutar la operación y devolver al saldo la diferencia entre máximo y coste real. Puede rechazar una petición cuyo máximo no cabe aunque su coste final hubiera cabido. El agente puede probar de nuevo con un máximo menor. El propósito es que la autorización sea un tope efectivo, no una alerta que llega con la factura.

El recurso mantiene además contadores de uso atribuidos a la persona. Eso no le permite inventarse un segundo techo agregado: desconoce el límite privado que conserva el emisor. La responsabilidad de sumar autorizaciones vivas recae en el servidor de la persona. La advertencia matemática del texto es clara: n tokens concurrentes de valor X permiten hasta nX durante su vigencia si el emisor no ajusta la suma. Se trata de una exposición que el borrador intenta controlar, no de un incidente observado. En una delegación a otro agente tampoco existe un subpresupuesto automático que se descuente del token original; se solicita otra autorización y vuelve a plantearse la suma.

La aritmética se complica cuando deja de haber noticias de un token. Puede caducar, ser sustituido al renovarse o quedar en manos de un agente interrumpido sin que el emisor conozca el consumo exacto. El proyecto exige contabilizar provisionalmente toda esa asignación como consumida. Un registro de consumo que acompañe a un nuevo desafío es una instantánea, no un cierre si el token sigue siendo válido. Una lectura del punto de consulta de uso, completa hasta su hora as_of, permite saldar las asignaciones que ya expiraron. La revocación confirmada en el recurso puede adelantar el momento; una revocación no soportada o cuyo resultado se desconoce no libera automáticamente el margen. Las operaciones que ya estaban en marcha pueden terminar. Pulsar «detener» tampoco borra cargos comprometidos.

El borrador también separa dos decisiones que una interfaz de presupuesto podría confundir. El importe limita cuánto consume el agente, no qué acción puede realizar. Una operación irreversible barata sigue necesitando un alcance autorizado. Y si la persona tiene varias cuentas facturables en el mismo recurso, el token presupuestario por sí solo no determina cuál paga; la vinculación de cuenta es otra decisión. El valor de saldo que propone la cabecera AAuth-Budget sirve al agente para ajustar el ritmo de sus llamadas, pero no va firmado por defecto ni es la fuente de la autorización. Firmar una respuesta del contador está recomendado, no exigido. La firma fija lo que el recurso dijo; no demuestra que midiera bien ni reemplaza el contraste con la factura.

Las implementaciones mencionadas en el propio borrador son declaraciones de sus autores; esta revisión no las ha comprobado de forma independiente. También queda fuera el caso corriente en que el proveedor del agente paga su propia inferencia sin pasar por el servidor de la persona. La cuestión aquí es más concreta: software agente que incurre en gasto sobre la cuenta medida de alguien más. En ese circuito, un límite por token es una pieza útil, pero la garantía agregada vive en otro lugar.

Fuentes