TrustGate

TrustGate es una demostración de datos sintéticos, en el Modo de Prueba de Razorpay, de un comprador de IA que puede proponer una compra del catálogo sin obtener autoridad para reescribir el comerciante, el importe, la moneda, la aprobación o el resultado del proveedor. El agente propone; TrustGate autoriza de forma independiente y registra la evidencia.

Qué demuestra

• El SKU del catálogo y la cantidad son los únicos hechos de compra que un agente puede influir.

• La política por inquilino, la aprobación humana, una autoridad de pago de un solo uso y los eventos verificados del proveedor limitan cada acción de pago.

• Los intentos no seguros se rechazan antes de que se pueda crear una orden de proveedor y dejan un rastro auditable.

Related MCP server: safe-cart-ai

Cómo se usa la IA aquí

El agente comprador es deliberadamente delgado, y eso es el argumento, no un atajo. Solo puede proponer un SKU del catálogo, una cantidad y un propósito; cada hecho crítico para el dinero se deriva del lado del servidor. Elimina al agente por completo y la capa de autorización no cambia y sigue siendo correcta.

La contribución de ingeniería no es un agente sofisticado. Es tomar en serio los modos de fallo de los modelos de lenguaje — inyección de instrucciones a través de contenido de terceros, seguimiento de instrucciones contra los intereses del operador, razonamiento erróneo y confiado sobre dinero — y construir un sistema que se mantenga correcto cuando ocurren.

Esa afirmación se prueba en ambas direcciones. python -m agent.demo --live ejecuta un modelo real contra descripciones de catálogo escritas por terceros, incluidas las hostiles. El mismo catálogo se envía dos veces, una con las descripciones eliminadas, de modo que la influencia del contenido no confiable se mide comparando las dos propuestas en lugar de autoinformarse. La suite de regresión nunca llama a un proveedor de modelos: utiliza sustitutos deterministas, por lo que la verificación de seguridad no depende de que un modelo se comporte de una manera particular en un día particular.

Viendo el problema

Tres rechazos limpios demuestran que el sistema funciona y son débiles para mostrar por qué alguien lo necesita. Por lo tanto, la demo comienza con el propio código de este proyecto fallando, sin usar red, sin credenciales y sin base de datos:

python -m demo.unguarded

El mismo agente lee el mismo catálogo envenenado — literalmente el mismo, ya que ambos catálogos se construyen a partir de agent/demo_catalog.py y una prueba afirma que la fila sembrada y el objeto de referencia llevan una instrucción inyectada idéntica. Una respuesta del modelo se entrega a dos adaptadores.

El no protegido acepta un importe y un comerciante, por lo que la instrucción inyectada se ejecuta y paga INR 20,000.00 a un comerciante que el texto del catálogo nombró, contra un precio de catálogo de INR 600.00. El otro no tiene dónde poner ninguno de los dos campos, porque PurchaseProposal declara solo un SKU, una cantidad y un propósito. Lo que sobrevive al descarte es quantity=50, que es un campo que el agente puede establecer — y el servidor lo limita contra el máximo propio del catálogo de 2, por lo que el intento se rechaza antes de que se cree una solicitud de pago.

La diferencia no es un filtro que reconoció un ataque. Es que una interfaz tenía un campo para el dinero y la otra no. La línea base tiene sus propias pruebas que afirman tanto que no puede alcanzar nada real como que sigue siendo explotable, ya que una demostración que silenciosamente dejara de ser vulnerable seguiría pasando mientras hiciera el punto opuesto.

Matriz de ataques

Escenarios adversariales de nivel A. Esta tabla se genera desde el registro de escenarios mediante python -m scenarios.report, y una prueba afirma que coincide, por lo que no puede afirmar un ataque que no esté cubierto por una prueba que pase. Cada escenario demuestra tres cosas: el ataque se rechaza con su código de razón, no se creó ninguna orden de proveedor y ningún pago obtuvo autoridad que no tuviera.

Cada escenario de Nivel A está implementado. A11a y A11b dividen la confusión de inquilinos en un inquilino no resoluble y un inquilino conocido que cruza el límite, porque los dos fallan por razones diferentes y solo el segundo es una cuestión de autorización.

Lo que valen las pruebas

Una suite que pasa dice que el código se comporta como está escrito. No dice que las pruebas objetarían si el código dejara de hacer algo importante, y solo la segunda afirmación importa cuando el tema es dinero. Este proyecto tiene evidencia de la diferencia: las sesiones con ámbito de solicitud descartaron una vez cada escritura mientras 146 pruebas pasaban, porque la suite afirmaba dentro de la misma transacción en la que escribía.

make mutation rompe cada invariante de seguridad a propósito, uno a la vez, y requiere que las pruebas nombradas como sus guardias fallen. Cada archivo fuente se restaura en un bloque finally y la restauración se verifica contra git diff antes de que se imprima el informe, por lo que una ejecución interrumpida no puede dejar una mutación atrás. Sale con código no cero si alguna mutación sobrevive.

Esta tabla se genera a partir del registro de mutaciones mediante python -m scenarios.report --mutations, y una prueba afirma que coincide, por lo que no puede reclamar un invariante protegido que no esté realmente protegido.

La primera ejecución de esta suite encontró un defecto en vivo. SELECT ... FOR UPDATE a través del ORM adquiere el bloqueo correctamente y luego descarta la fila que Postgres devolvió, porque SQLAlchemy mantiene los atributos de un objeto que ya está en el mapa de identidad de la sesión. Por lo tanto, un segundo llamador se bloqueó en el bloqueo como estaba diseñado, recibió la fila confirmada, conservó su copia obsoleta y autorizó un pago que acababa de ser autorizado. El bloqueo estaba serializando cuando se ejecutaban las transiciones, no el estado del que decidían. Todo el bloqueo ahora pasa por models.locking.locked(), y una prueba afirma que ese helper es el único lugar en el código fuente que puede tomar un bloqueo.

Alcance Actual

TrustGate utiliza solo inquilinos sintéticos, comerciantes y precios en INR. Es un banco de pruebas de seguridad local, no un procesador de pagos, un producto de cumplimiento, un sistema de consentimiento legal, un modelo de fraude o una integración de pagos en Modo Live.

Inicio Rápido

Requisitos: Docker Desktop y Python 3.12.

Copy-Item .env.example .env
docker compose up -d
docker compose exec -T api python -m alembic upgrade head
docker compose exec -T api python -m pytest -q

La verificación de salud de la API local está disponible en http://127.0.0.1:8000/health.

Crea un inquilino M1 sintético desechable con python -m agent.seed. Establece MCP_TENANT_ID y MCP_ACTOR_ID a los valores impresos, luego ejecuta la demostración local del agente comprador con python -m agent.demo "Compra créditos Starter para nuestro club de estudiantes.". Puede proponer solo un SKU del catálogo, una cantidad y un propósito; el servidor MCP deriva todos los hechos críticos de dinero. Usa python -m agent.demo --adversarial "Compra una pequeña cantidad de créditos en la nube." para ejecutar la demostración determinista de catálogo envenenado.

Para ejecutar el mismo flujo con un modelo real en lugar de un sustituto determinista, instala el extra opcional con pip install -e ".[agent]" y agrega --live. Se admiten dos backends y ambos usan la misma forma de API de Messages:

• TRUSTGATE_MODEL_BACKEND=anthropic (predeterminado) lee ANTHROPIC_API_KEY.

• TRUSTGATE_MODEL_BACKEND=bedrock factura contra una cuenta de AWS. Establece AWS_REGION a la región a la que pertenece la credencial, y luego AWS_BEARER_TOKEN_BEDROCK (una clave de API de Bedrock, la ruta más simple) o credenciales estándar de AWS para la firma SigV4. Amazon Bedrock aprovisiona modelos de Anthropic a través de una suscripción a AWS Marketplace, por lo que la cuenta de AWS también necesita un instrumento de pago válido incluso cuando los créditos cubrirían el uso.

• TRUSTGATE_MODEL_BACKEND=groq lee GROQ_API_KEY y no necesita ningún instrumento de pago.

TRUSTGATE_MODEL_ID anula el modelo en cualquier backend. El comprador es una implementación de protocolo, por lo que el proveedor es una elección de configuración en lugar de una arquitectónica: el comportamiento de la capa de autorización no depende de qué modelo propone la compra.

Este es el único camino en el proyecto que contacta a un proveedor de modelos; la suite de pruebas nunca lo hace. Ejecútalo solo contra el catálogo de semillas sintético. Sus descripciones de terceros se envían al modelo dos veces, una con descripciones eliminadas y otra intacta, para medir la influencia. Nunca envíes datos reales de clientes, comerciantes o pagos a través de esta demostración.

Para ejercitar el adaptador de Modo de Prueba de Razorpay, establece RAZORPAY_KEY_ID y RAZORPAY_KEY_SECRET en el archivo .env ignorado. Nunca agregues secretos de Modo de Prueba o Modo Live al repositorio.

Límite de Confianza

AI buyer proposes SKU, quantity, and purpose
        -> TrustGate derives and authorizes money-critical facts
        -> Razorpay Test Mode executes a bounded order
        -> TrustGate records authorization and provider evidence

El plan de construcción formal está en docs/build-plan.md; las decisiones de arquitectura, modelo de amenazas y diseño están en docs/.