Un protocolo de confianza para
la autorización del efecto exacto.
SecureStamp extiende la confianza digital desde el origen y la intención hasta la ejecución. Las decisiones aprobadas se convierten en autoridades de ejecución acotadas, limitadas por una política que controla el cliente y seguidas de evidencia verificable de forma independiente.
Gmail, Outlook y Apple Mail, con evidencia de origen en la bandeja
Canales oficiales
WhatsApp, Telegram y el perímetro que declara una marca
Agentes y APIs
Herramientas MCP, APIs y workflows autónomos
Arquitectura del protocolo
Confianza antes de actuar. Evidencia después de ejecutar.
Un solo stack de confianza, aplicado en todas las superficies.
SecureStamp no es un verificador de email con una función de agentes agregada encima. Origen, intención, autorización de ejecución y evidencia de ejecución son cuatro capas de una misma cadena — y esa cadena funciona igual si la instrucción llega a una bandeja de entrada, a un mensajero o a través de una llamada de herramienta MCP.
SecureStamp extiende la confianza desde la instrucción hasta la consecuencia.
Stack de confianza
Origen
¿De dónde viene? Dominios, headers, firmas, identidad declarada y perímetro de canal. Evidencia de apoyo: necesaria, y nunca el titular.
Intención
¿Qué se está pidiendo? La acción solicitada se lee y se enuncia primero: pagar, aprobar, entregar credenciales, invocar una herramienta. Es una señal de entrada, no una prueba.
Execution Authorization
¿Qué efecto exacto se puede causar? Una decisión aprobada se convierte en una autoridad acotada y de un solo uso para una operación canónica bajo restricciones explícitas.
Evidencia de ejecución
¿Qué autorización se consumió y qué resultado pudo establecer el punto de ejecución? Un receipt firmado que cualquiera puede verificar sin conexión.
Aplicado en
Gmail · Outlook · Apple Mail
Canales oficiales
WhatsApp · Telegram · perímetros declarados
Agentes
Clientes MCP y copilotos
APIs
Integraciones directas
Workflows
Automatizaciones y servicios delegados
Execution Authorization aplica dondequiera que se delegue autoridad a software, no solo a agentes de IA. Una automatización, un workflow o un servicio delegado actuando en nombre de otro plantean la misma pregunta: ¿qué efecto exacto se aprobó?
Tesis del protocolo
El nuevo perímetro es la acción.
Primero defendimos dispositivos contra malware y troyanos. Después defendimos bandejas de entrada contra phishing. Ahora el software actúa en nuestro nombre, y la pregunta ya no es solo a qué puede llegar: es qué puede cambiar.
Mensajes, eventos y prompts pueden activar APIs, tool calls, workflows y operaciones monetarias digitales. SecureStamp propone señales verificables antes de que una comunicación se convierta en acción.
La identidad controla quién puede acceder a un sistema. SecureStamp acota el efecto exacto que el software autónomo puede causar.
Cuatro capas
La autenticación establece identidad. El control de acceso limita el alcance. Execution Authorization acota el efecto.
Autenticación
¿Quién o qué está actuando?
Autorización de acceso
¿A qué recursos puede llegar?
Execution Authorization
¿Qué efecto exacto puede causar?
Evidencia de ejecución
¿Qué autorización se consumió y qué resultado pudo establecer el punto de ejecución?
La cuarta pregunta está redactada a propósito. Un resultado que no se puede establecer queda como indeterminate, y ninguna capa de este stack pretende lo contrario.
Dónde estamos
SecureStamp empieza donde termina la decisión.
Los sistemas de identidad, política y aprobación deciden si una acción debe proceder. SecureStamp vincula esa decisión aprobada con el efecto exacto que se puede ejecutar.
Decidir
¿Qué debería permitirse? Lo responden identidad, motores de política, aprobaciones y personas.
Autorizar
¿Qué efecto exacto se permite? Esta es la capa que agrega SecureStamp.
Ejecutar
Aplicar ese efecto dentro de las restricciones del cliente, en un punto que el cliente controla.
Verificar
¿Qué autorización se consumió y qué resultado pudo establecer el punto de ejecución?
SecureStamp no reemplaza identidad, motores de política, flujos de aprobación ni las APIs del proveedor. Vincula sus decisiones aprobadas con efectos ejecutables exactos.
SecureStamp entrega señales verificables y autorizaciones acotadas. No reemplaza políticas internas, permisos, sandboxing, aprobación humana ni los controles de seguridad existentes.
Dispositivos
El primer perímetro moderno fue el dispositivo: malware, troyanos, archivos peligrosos y comportamiento local.
Bandejas de entrada
Después el riesgo se movió al mensaje: dominios parecidos, links falsos, adjuntos, urgencias de pago y suplantación.
Acciones
Ahora una instrucción puede abrir herramientas, invocar APIs, procesar facturas, mover datos o preparar pagos.
Trust checks
SecureStamp lee qué pide un mensaje —pagar, aprobar, entregar credenciales, invocar una herramienta— y lo respalda con evidencia de origen, canal y contexto antes de responder, pagar, compartir datos o ejecutar workflows.
Agnóstico de canal
Un estándar agnóstico de canal
SecureStamp no está diseñado para un único inbox, app o industria. El protocolo organiza señales alrededor de origen, canal, intención declarada y acción. Puede aplicarse a email, mensajería, QR, sitios web, facturas, tickets, APIs, agentes y operaciones monetarias digitales.
Autoridad delegada
Dondequiera que se delegue autoridad a software.
Un agente, una automatización, un workflow o un servicio delegado actuando en nombre de otro plantean la misma pregunta. El permiso de acceso dice a qué pueden llegar; no define el efecto exacto aprobado para esta transacción.
MCP para agentes
SecureStamp MCP Server
MCP es la vía por la que las aplicaciones de IA alcanzan herramientas, datos y workflows. SecureStamp se pone delante de ese alcance: el software pregunta qué está pidiendo realmente una instrucción, quién es la contraparte y qué efecto exacto puede causar, antes de que algo se ejecute.
SecureStamp autoriza; nunca tiene tus credenciales de proveedor. Cuando una operación realmente debe ejecutarse, el grant firmado viaja a un Execution Guardian que corrés vos, y solo ese daemon toca al proveedor.
read_message_request(...)analyze_message_intent(...)verify_counterparty(...)get_safe_next_step(...)authorize_action(...)create_action_challenge(...)issue_action_receipt(...)get_source_envelope(...)request_execution_grant(...)get_execution_status(...)Flujo conceptual
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
SSF organiza primero la acción solicitada y después las señales de contenido, origen, autenticación, canal y contexto, para producir una salida simple, auditable y legible por humanos, sistemas y agentes.
Requested Action
Responder, abrir, pagar, transferir, aprobar, compartir datos, invocar herramientas o ejecutar workflows.
Content Signals
Urgencia, links, adjuntos, credenciales, instrucciones de pago y cambios de cuenta bancaria.
Origin Signals
Dominio, organización, identidad declarada, emisor.
Technical Signals
SPF, DKIM, DMARC, DNS TXT, headers, firmas, claves y receipts.
Channel Signals
Email, web, WhatsApp, Telegram, QR, API, soporte, facturación y tickets.
Verdict Layer
Trust, Signal y Action Verdict: una salida legible y auditable que dice primero qué se pide y muestra la evidencia de origen debajo.
Tres señales de entrada, después la autorización
Proof of Origin responde de dónde vino una instrucción. Proof of Intent enuncia qué está pidiendo. Action Verdict recomienda si debería proceder. Las tres son señales que alimentan una decisión — y una decisión todavía no es una autorización.
Proof of Intent
¿Qué se está pidiendo? Señal de entrada que enuncia primero la acción solicitada. No es una prueba de qué se autorizó.
Proof of Origin
¿De dónde viene? Dominio, organización, canal, remitente, sello y señales técnicas. Evidencia de apoyo.
Action Verdict
¿Debería proceder? Señal de decisión. Lo que ocurre después de esa decisión es Execution Authorization.
Capa de ejecución
Public Beta · acceso productivo controladoUn veredicto no es una prueba.
Un veredicto puede recomendar si una acción debería proceder. Por sí solo no prueba el efecto exacto que se autorizó, la autoridad que lo respaldó, si esa autorización se reutilizó, ni el resultado observado en la ejecución.
Action Proof crea esa cadena de evidencia. Una decisión aprobada se convierte en autoridad ejecutable acotada: un efecto exacto, una autoridad, un vencimiento, un solo uso — verificable sin conexión, por cualquiera.
El acceso no es autorización para actuar
El acceso controla a qué puede llegar el software. Execution Authorization acota el efecto exacto que puede causar.
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.
Autorizá el efecto, no solo el acceso a la herramienta.
Techo controlado por el cliente
Tu política es el techo.
SecureStamp Cloud puede hacer una autorización más estrecha. No puede hacerla más amplia que la política que tu organización firmó e instaló localmente. La autorización de la nube es necesaria, pero nunca suficiente por sí sola.
Permiso efectivo
permiso efectivo =
grant de la nube
∩ política local firmada
∩ restricciones del adaptador
∩ kill switches- La política local es un documento que tu organización firma con su propia clave e instala junto al Guardian. 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.
- Es deny-only por construcción. No tiene ningún campo capaz de conceder algo que la nube no concedió.
- Arrancar en modo productivo sin una política local firmada y válida no se advierte: se rechaza en el arranque.
- Los kill switches existen a nivel global y por proveedor, operación, tenant y gateway — y otra vez dentro de la propia política local. Detienen grants ya emitidos.
- Las políticas llevan una fecha de revisión obligatoria y un vencimiento opcional. Una política vencida bloquea nuevas mutaciones y deja intactos el estado, la prueba, la relectura y la reconciliación.
- La recuperación de claves es M-de-N y offline. El soporte de SecureStamp no puede sustituir ese control, y ese es exactamente el punto.
- Un plano de control en la nube comprometido sigue sin poder exceder la autoridad permitida localmente.
Hospedado por el cliente
Nosotros autorizamos. Vos ejecutás.
El Guardian corre en tu entorno y conserva las credenciales del proveedor. SecureStamp Cloud no recibe credenciales de proveedor y nunca llama a tu proveedor.
- Las credenciales del proveedor se montan como archivos propiedad de root, nunca como variables de entorno ni configuración embebida.
- El bridge MCP —el proceso más cercano al modelo— no necesita credenciales de proveedor ni SDKs de nube.
- El efecto se resuelve a partir del estado que lee el propio daemon, nunca de parámetros que aportó el modelo.
- El estado previo se relee inmediatamente antes de la mutación; un cambio material invalida el grant en lugar de sobrescribirlo.
Cadena de prueba
Cinco eslabones, cada uno firmado por una parte distinta
Prueba criptográfica de la autorización. Evidencia firmada del resultado de la ejecución.
Source Envelope
El plugin firma lo que la persona realmente vio, en el dispositivo, con una clave que nunca sale de ahí. El cuerpo del mensaje jamás se transmite.
Action Effect
El Guardian —no el modelo— lee el estado del proveedor y normaliza el efecto exacto: proveedor, operación, recursos, parámetros y un digest del estado previo.
Execution Grant
SecureStamp Cloud firma un grant de un solo uso vinculado a ese digest, a la autoridad que lo aprobó, a la versión de política vigente y a un vencimiento. maxUses es 1, siempre.
Execution Claim
Tu Guardian reclama el grant contra su propio ledger. Un grant reproducido se rechaza antes de contactar a ningún proveedor.
Action Receipt
El Guardian firma la autorización consumida, el contexto de ejecución y el resultado que pudo establecer, junto con el digest de la política local que lo acotó.
Autoridad
Ningún pedido trae su propio permiso.
La autoridad que exige una operación la fija el protocolo. Quien llama no puede elegirla, el modelo no puede argumentar a favor de ella y no se puede degradar dentro del mismo pedido que la necesita. Los perfiles de quórum son snapshots de política firmados, no valores de autoridad: estándar y elevado son etiquetas para personas, mientras que la prueba se apoya en el umbral, la lista de aprobadores y el hash de la política.
noneNunca concede ejecución. Existe para que su ausencia sea explícita en lugar de implícita.
policy_delegatedAutonomía dentro de una política que la organización definió de antemano, y solo para un pedido firmado en el dispositivo. Nunca para uno correlacionado.
human_mfaUna persona identificada aprueba contra una sesión MFA viva. Se usa donde el efecto es acotado y reversible en la práctica.
quorumM-de-N aprobadores independientes, cada uno con su propia sesión MFA, contra una política definida de antemano. Quien pide nunca puede aprobar su propio pedido. Obligatorio para toda concesión de privilegio.
Seguridad ante el fallo
Lo desconocido sigue siendo desconocido.
Una respuesta ambigua del proveedor queda como indeterminate hasta la reconciliación. Las operaciones que mutan estado no se reintentan a ciegas.
Una API de pagos hace timeout después de recibir una mutación. Repetirla puede duplicar el efecto. SecureStamp no asume el fallo y reintenta: el Guardian reconcilia el estado del proveedor y puede devolver indeterminate. La ambigüedad es un resultado de primera clase y nunca se redondea a éxito.
Verificación independiente
Comprobá la cadena sin preguntarnos.
El verificador es un paquete publicado sin acceso a red. Recalcula sin conexión cada digest y cada firma de un proof bundle, incluidos el hash del snapshot de política y el digest de la política local firmada. 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.jsonEl verificador se publica antes que los artefactos que verifica. Nunca se emite una versión nueva de receipt o bundle antes de que un verificador ya publicado la acepte.
Conectores
Traé el punto de ejecución que ya usás.
El modelo de autorización de SecureStamp es independiente del proveedor. Estos son conectores de referencia, no un catálogo cerrado. Cómo se integra un conector y cuánto responde SecureStamp por él son dos preguntas distintas, y las mantenemos separadas a propósito.
Cómo se conecta
Adaptador certificado
Un módulo que escribimos, revisamos y vinculamos a evidencia de certificación publicada.
Adaptador HTTPS declarativo
Origen, método y path fijados al instalar. Sin URL, método ni headers arbitrarios del modelo, sin redirects, schema estricto e idempotencia determinista.
SDK / sidecar
Para protocolos que no pueden satisfacer el contrato declarativo, sobre un socket Unix.
Cómo se declara su garantía
SecureStamp Certified
Lo escribimos, lo revisamos y publicamos la evidencia.
Partner Attested
Un partner identificado responde por él, y el bundle lo dice.
Customer Defined
Lo construiste vos. La cadena igual verifica, y el bundle declara con todas las letras que SecureStamp no certificó el código del conector.
Los adaptadores traducen un efecto autorizado a la ejecución específica de un proveedor. No redefinen la autoridad concedida.
Stripe
refund.createhuman_mfaOkta
group.add_userhuman_mfaAWS
iam.attach_role_policyquorumGoogle Cloud
iam.project_binding.addquorumAzure
rbac.role_assignment.createquorumMicrosoft Entra
pim.directory_role_assignment.createquorumEncaja en tu plano de control
Funciona con los controles que ya tenés.
SecureStamp no reemplaza identidad, motores de política, flujos de aprobación ni las APIs del proveedor. Vincula sus decisiones aprobadas con efectos ejecutables exactos.
Límites de la evidencia
Qué establece un receipt y qué no.
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.
Las acciones realizadas fuera de ese camino quedan fuera del alcance del receipt.
Estado de release
Por qué estos paquetes siguen diciendo beta.
El protocolo, el código y el verificador están completos y son auditables hoy. Pero no llamamos estable a un conector hasta publicar evidencia de 100 ejecuciones reales contra un proveedor vivo —con inyección de fallos, rechazo de reproducción y prueba de que la credencial no podría haber hecho más— vinculada al commit exacto que las produjo. La ejecución productiva requiere opt-in explícito y elegibilidad del conector, y hasta que un conector supere ese gate su Guardian se niega a correr fuera de modo sandbox. Un producto de confianza que te pide que le creas ya fracasó.
Paquetes
@securestamp/action-proof-verifyEl verificador offline y sus contratos de verificación. Se publica antes que todo lo que verifica.
@securestamp/action-proofContratos, firma y proof bundles.
@securestamp/execution-guardianEl daemon hospedado por el cliente y sus conectores de proveedor.
@securestamp/execution-guardian-mcpEl bridge MCP. Sin credenciales, sin SDKs de nube, por construcción.
Trust Levels
Trust Level explica el origen. Action Verdict ayuda a decidir la acción.
Los niveles L1-L5 gradúan la evidencia verificable de origen. No afirman que el contenido sea verdadero ni que una acción deba ejecutarse automáticamente.
L1
Registrado
El dominio u organización está registrado en SecureStamp.
L2
Alineado
Señales técnicas como SPF, DKIM, DMARC o DNS están alineadas.
L3
Firmado
El mensaje, canal o evento incluye un token firmado y verificable.
L4
Notarizado
Existe una referencia verificable de integridad o receipt para auditoría posterior.
L5
Certificado
La identidad organizacional detrás del origen fue revisada con evidencia adicional.
Origen verificado no significa acción aprobada
Trust Level describe la fuerza de la evidencia sobre el origen. Action Verdict evalúa una acción concreta usando SSF, contexto y política. Un origen legítimo todavía puede pedir una acción que requiera revisión.
Puntos de integración
Cuatro formas de declarar y consultar confianza
DNS TXT record
Publicá un TXT record bajo _securestamp.[dominio]. Los verificadores resuelven el subdominio y validan el origen declarado sin inspeccionar contenido privado.
- —v=1 — versión del protocolo
- —id=<stamp_id> — identificador verificable
- —url=<verify_url> — URL canónica de verificación
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
Inyectá X-SecureStamp en mensajes salientes para que clientes, plugins y gateways consulten origen y estado con señales firmadas.
- —Token firmado por el emisor o nodo autorizado
- —Claims mínimos: stampId, domain, orgId, score, exp
- —Clave pública o referencia verificable para validación
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
Consultá dominios, canales o acciones sin guardar instrucciones sensibles en claro. Las respuestas pueden incluir señales, reasons y Trust Receipts.
- —Trust checks para dominios y canales
- —Action Verdict para acciones sensibles
- —Receipts verificables para auditoría
- —Verificador público y registry cuando aplica
GET https://securestamp.org/v1/trust/example.com{
"domain": "example.com",
"trustLevel": "L3",
"signals": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
"actionVerdict": "needs_confirmation",
"receiptRef": "tr_01h..."
}MCP Server
Capa activa de Agent Trust para que agentes consulten trust checks antes de tool calls, APIs, workflows y operaciones sensibles.
- —SecureStamp MCP Server
- —Tool call checks
- —Action Verdict antes de ejecutar
- —Human approval cuando la política lo requiera
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
Verificación de canales oficiales en superficies conversacionales
Signal permite consultar si un número, bot, handle, link, cuenta o punto de contacto pertenece al perímetro oficial declarado por una entidad. Es la capa para WhatsApp, Telegram, web, QR, soporte, facturación y otros canales donde una persona o agente puede recibir instrucciones sensibles.
Perímetro oficial
Contrasta canales de email, WhatsApp, Telegram, web, QR, soporte y facturación contra registros verificables.
Conectado con SSF
Las señales de canal alimentan Trust, Action Verdict y receipts sin convertir una marca en garantía absoluta.
Límite honesto
Signal verifica pertenencia al perímetro oficial. No prueba que cada mensaje sea verdadero.
Receipts, registry y auditoría
Evidencia auditable sin depender de capturas de pantalla
Cada consulta o declaración relevante puede generar un receipt verificable. Los receipts ayudan a auditar origen, canal, intención declarada y Action Verdict sin depender de confianza ciega en una interfaz.
Trust Receipts
Comprobantes firmados que resumen señal, contexto permitido, timestamp y referencia verificable.
Registry
Tokens, receipts y referencias públicas pueden verificarse sin autenticar cuando el flujo lo permite.
Auditoría
Las organizaciones pueden combinar receipts con políticas internas, aprobaciones y controles de cumplimiento.
Glosario público
Un lenguaje común para usuarios, soporte e integradores
El glosario explica términos de SecureStamp, email, criptografía, Signal, E2EE, APIs e infraestructura para que una persona no técnica o un developer junior entienda qué está leyendo.
Abrir el glosarioTérminos SecureStamp
Conceptos creados o definidos por SecureStamp para explicar confianza, sellos, recibos y perímetros verificables.
Email, dominios y autenticación
Abreviaciones clásicas que aparecen cuando SecureStamp explica si un remitente o dominio está bien autenticado.
Criptografía y seguridad
Términos necesarios para entender firmas, cifrado, claves, logs verificables y recuperación empresarial.
Protocolos, APIs e infraestructura
Lenguaje común para developers junior e integradores que leen APIs, plugins, dashboards o runbooks.
Red federada
Red federada y nodos aprobados
SecureStamp Foundation coordina una red de nodos aprobados para escribir y verificar registros compartidos. Operar un nodo requiere revisión técnica, SLA y alineación con principios de governance.
Enviar solicitud
Incluí organización, región, capacidad operativa, SLA previsto, superficie técnica y caso de uso declarado.
Revisión técnica
La fundación evalúa capacidad, seguridad operacional, cobertura y potenciales conflictos de interés.
Credenciales emitidas
Si se aprueba, el operador recibe credenciales y requisitos de integración para participar en la red.
Operación auditada
El nodo debe mantener disponibilidad, salud pública, trazabilidad operativa y procesos de respuesta ante incidentes.
Obligaciones del nodo
Registro verificable
Verificar sellos, receipts y referencias públicas
Cada sello, receipt o referencia pública emitida por SecureStamp puede verificarse sin convertir el sitio en una landing comercial. La fundación mantiene el estándar y los puntos de consulta.
securestamp.org/verify/[token]FAQ técnica
Preguntas frecuentes para developers e integradores
¿Qué es SecureStamp Foundation?
La entidad que publica y gobierna el estándar abierto de SecureStamp para verificar origen, intención, canal y acción antes de operar.
¿Qué problema resuelve el protocolo?
Ayuda a humanos, sistemas y agentes a consultar señales verificables antes de responder, pagar, compartir datos, invocar APIs o ejecutar workflows.
¿Cómo se relacionan el stack de confianza y las superficies?
El stack de confianza es Origen, Intención, Execution Authorization y Evidencia de ejecución. Las superficies son email, canales oficiales, agentes, APIs y workflows. Son dos ejes independientes: el mismo stack se aplica en todas las superficies, y Execution Authorization es una capa, nunca una superficie aparte.
¿Qué es Proof of Origin?
La evidencia verificable de que un dominio, canal, emisor u organización corresponde a un origen registrado.
¿Qué es Execution Authorization?
El proceso de vincular una decisión aprobada con una autoridad acotada y específica de una transacción, que permite al software causar un efecto definido bajo restricciones explícitas. El control de acceso limita a qué puede llegar el software; Execution Authorization acota el efecto exacto que puede causar.
¿Qué es Action Verdict?
Una evaluación de una acción concreta antes de ejecutarla. Puede recomendar permitir, revisar, negar o pedir aprobación humana según señales y política.
¿Qué es SSF?
SecureStamp Signal Framework: un lenguaje común para señales de origen, autenticación, canal, contenido, contexto, acción y verdict.
¿Qué es SecureStamp MCP Server?
Una dirección developer preview para que agentes consulten trust checks antes de tool calls sensibles mediante Model Context Protocol.
Docs y especificación
Documentación del protocolo
La especificación cubre Proof of Origin, Proof of Intent, SSF, Action Verdict, puntos de integración, receipts, límites honestos y dirección MCP para agentes.
¿Preguntas sobre la especificación o el diseño del protocolo? protocol@securestamp.org
Contacto
Contactanos
Cada dirección va directo al equipo correspondiente. Sin sistema de tickets — personas reales.