Autorizá el efecto, no solo el acceso a la herramienta.
El control de acceso limita a qué puede llegar el software. Execution Authorization acota el efecto exacto que puede causar. Action Proof es el protocolo que produce la cadena verificable: un grant firmado y de un solo uso para una operación canónica, aplicado en un punto que controlás vos, y cerrado con evidencia que cualquiera puede comprobar sin conexión.
Prueba criptográfica de la autorización. Evidencia firmada del resultado de la ejecución. Un Execution Grant prueba qué se autorizó; un Action Receipt conserva evidencia firmada del resultado que el Guardian enrolado pudo establecer.
La nube autoriza, tu Guardian ejecuta
Claves por tenant, credenciales de mínimo privilegio
Receipts firmados, verificables sin conexión
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc":"2.0", "id":1, "method":"tools/list" }El acceso no es autorización para actuar
Tener acceso a la procesadora de pagos no es lo mismo que estar autorizado a hacer un reembolso concreto.
Acceso
El agente puede llamar a las APIs de reembolso de la procesadora de pagos
Execution Authorization
refund.create charge ch_89172 amount USD 1.427,00 destination original_payment_method maxUses 1 expires 14:02 UTC
La autorización de recursos responde a qué puede acceder un principal. Execution Authorization responde qué efecto específico de una transacción puede causar. Un acceso fine-grained sigue dejando la transacción sin definir: qué recurso, qué monto, qué destino, cuántas veces.
Tres pasos
Definir
¿Qué efecto exacto se está pidiendo? El Guardian —no el modelo— lee el estado del proveedor y lo normaliza en una operación canónica con parámetros explícitos.
Autorizar
Vincular ese efecto a un Execution Grant firmado y de un solo uso dentro de tu política, con la autoridad que el protocolo exige para esa operación.
Verificar
Ejecutar en un punto que controlás y conservar un Action Receipt firmado que se recalcula sin conexión.
read_message_request
Devuelve qué está pidiendo un mensaje, sólo desde señales. El cuerpo nunca sale del dispositivo.
analyze_message_intent
Mapea señales abstractas a intenciones de acción sensible. Sólo señales; nunca texto crudo.
verify_counterparty
Verifica si un remitente o contraparte coincide con el registro del tenant.
get_safe_next_step
Calcula el próximo paso más seguro a partir de hechos declarados en el registro.
authorize_action
Devuelve un Action Verdict, un Safe Next Step y un recibo antes de una acción sensible.
create_action_challenge
Crea un challenge manual de doble control para una contraparte conocida.
issue_action_receipt
Emite un Action Receipt firmado sobre hechos ya calculados.
get_source_envelope
Recupera el envelope firmado en el dispositivo que una persona realmente vio y aprobó.
request_execution_grant
Pide un grant de un solo uso para ejecutar un efecto exacto. Devuelve un HOLD hasta que apruebe la autoridad humana o el quórum requerido.
get_execution_status
Informa en qué estado está una ejecución, incluidos los resultados que siguen genuinamente indeterminados.
Capa de ejecución
El grant no es permiso para improvisar
Un Execution Grant está vinculado a un digest de efecto y a la versión de política vigente, vence y se puede usar exactamente una vez. Tu Guardian relee el estado del proveedor inmediatamente antes de mutar, reclama el grant contra su propio ledger y firma el resultado, incluidos los resultados ambiguos. Un grant reproducido nunca llega a un proveedor.
- Los grants son de un solo uso y están vinculados a un digest de efecto exacto. maxUses es 1, siempre.
- La autoridad requerida la fija el protocolo; quien llama no puede degradarla.
- Toda concesión de privilegio requiere quórum M-de-N, y quien pide nunca puede aprobar su propio pedido.
- Los perfiles de quórum son snapshots de política firmados, no valores de autoridad: la prueba se apoya en el umbral, la lista de aprobadores y el hash de la política.
- Los resultados son succeeded, failed_no_effect o indeterminate — la ambigüedad nunca se redondea.
- Los proof bundles verifican sin conexión, sin ninguna llamada de vuelta a SecureStamp.
Parábola 3
El agente se detiene antes de cambiar una cuenta
Un workflow recibe un pedido de cambio de cuenta bancaria de un proveedor. En vez de actualizar la cuenta, llama a authorize_action a través del MCP Guard remoto con un hash y señales abstractas. SecureStamp devuelve needs_confirmation y un Safe Next Step: desafiar a la contraparte. Nada se ejecuta hasta que responda una persona.
El agente identifica una acción sensible
Identifica un cambio de cuenta bancaria y envía solo señales estructuradas más un sourceMessageHash.
SecureStamp consulta hechos del tenant
La API key limita el lookup a un solo grafo de dueño, políticas declaradas e instrucciones registradas.
El agente recibe un veredicto
La respuesta es un hecho de decisión con Safe Next Step y receiptId, no permiso para ejecutar.
Humanos o contrapartes confirman
Si hace falta, create_action_challenge abre una confirmación manual antes de que la operación avance.
Techo local de autorización
La autorización de la nube es necesaria, pero nunca suficiente por sí sola.
Un grant solo se convierte en ejecución si además entra en la política que tu organización firmó e instaló junto al Guardian. Esa política es deny-only: fija tenant, gateway, operaciones, manifests de adaptador, autoridades y versiones de política aceptadas, recursos, parámetros, límites monetarios, concurrencia y destinos de red. El modo productivo se niega a arrancar sin una.
permiso efectivo =
grant de la nube
∩ política local firmada
∩ restricciones del adaptador
∩ kill switchesSecureStamp Cloud puede hacer una autorización más estrecha. No puede hacerla más amplia que lo que tu organización permitió localmente.
Contratos
Qué recalcula el verificador
ExecutionGrantV1El artefacto de autorización. Lleva el digest del efecto, la autoridad, la versión de política (apol_v1:) y el vencimiento. maxUses es 1.
ActionReceiptV2 / V3El artefacto de evidencia. V3 agrega la versión de política y el digest de la política local firmada (gpol_v1:) que acotó la ejecución. V2 sigue siendo byte-compatible para la historia.
ActionProofBundleV1 / V2Todo lo que un tercero necesita para recalcular la cadena. V2 agrega la política local firmada y el descriptor de assurance del conector.
AdapterManifestV1Descriptor autocontenido e inmutable de una operación de conector. El verificador comprueba el manifest del bundle en lugar de regenerarlo, así las operaciones nuevas nunca invalidan pruebas viejas.
Verificar un receipt sin conexión
El verificador es un paquete publicado aparte, sin acceso a red, y se publica antes que los artefactos que verifica. Los receipts se verifican sin conexión y sin contactar a SecureStamp, y la verificación no depende de que haya un servicio de SecureStamp funcionando.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json
Límites de la evidencia
Un Action Receipt prueba qué pasó por un Guardian enrolado y el resultado que ese Guardian pudo establecer. No prueba que no haya ocurrido ninguna acción fuera de SecureStamp, ni establece la propiedad legal de la cuenta del proveedor. El límite de la evidencia es el camino de ejecución enrolado.