Lo que escribe el agente

“¿Esta cosa puede tocar mi infraestructura?”

No. WhyStack es de solo lectura por construcción, con exactamente cinco excepciones, y ninguna de ellas toca tu infraestructura. Las cinco escriben en sistemas de registro: tickets, chat e issues, que es donde un incidente se anota y se comunica.

Las cinco

Tool	Dónde escribe	Operación ejecutada
create_incident_ticket	Jira	tickets.createIssue
update_jira_issue	Jira	tickets.transitionIssue, tickets.addComment
post_slack_message	Slack	chat.postMessage
create_slack_channel	Slack	chat.createChannel
create_github_issue	GitHub	tickets.createGithubIssue

El criterio, y lo que deja fuera

La lista no es arbitraria ni meramente histórica. Una escritura entra cuando es un registro reversible, en el lugar donde tu equipo ya trabaja: afirma que algo merece atención, no cambia lo que corre en producción, y deshacerla cuesta un clic y deja rastro. Un issue de GitHub pasa esa prueba por la misma razón que un ticket de Jira: muchos equipos usan uno donde otros usan el otro.

Un pull request no pasa, y el rechazo es deliberado. Un PR propone código, y el valor de proponer código está en que alguien lo acepte. Así que el modo de falla no es “abrieron un PR de más”, es alguien haciendo merge de un diff escrito sobre una causa que el agente infirió. El contraargumento obvio (“un PR pasa por revisión humana por construcción”) es débil por una razón que medimos: en cinco hallazgos de nuestro propio ciclo de mejora, el síntoma era correcto en los cinco y el mecanismo propuesto, incorrecto en cuatro. La revisión de un PR es un gate contra el código malo, no contra una causa equivocada.

AWS, GCP, Magalu y Datadog quedan fuera, y ahora por una razón explícita en lugar de una heredada: eso es infraestructura, no registro.

Escribir en GitHub es opcional, y lo que decide es la credencial

Si el token que le diste al Agent no tiene alcance de escritura, la operación falla dentro de tu infraestructura y la tool desaparece de la superficie: el agente nunca la ve y no puede llamarla. No hay un flag para desactivarla porque no hace falta: el interruptor es el alcance del token, que ya está en tus manos. Es el mismo diseño que el de cualquier connector que decidas no configurar.

Nada en AWS, GCP, Magalu, Datadog, Argo CD ni en ninguna base de datos, y en GitHub solo el issue

Esto no es una configuración que alguien pueda aflojar. La garantía es el catálogo: no existe ninguna operación de escritura para esos servicios (existen seis en total, y las seis son de Jira, Slack e issues de GitHub), y el Agent, dentro de tu infra, rechaza cualquier operación que no esté en el catálogo. Y el conteo está garantizado por un test: el CI enumera las operaciones de escritura y falla, nombrando la que apareció, si dejan de ser exactamente estas seis o si alguna sale de ticket, chat o issue. Lo mismo vale, del otro lado, para estas cinco tools. Algunos connectors llevan una capa más: un test que lee el propio código fuente del connector y falla si aparece un verbo de escritura (hoy: Magalu, Vercel, Argo CD y GitHub, donde la única llamada mutante permitida es la que abre un issue). En Argo CD esa capa va más allá del verbo: como su API sincroniza, hace rollback y borra aplicaciones, el test también rechaza las rutas de esas acciones y el parámetro refresh, que es una lectura con efecto de escritura. Fuerza una reconciliación en tu clúster. Los rollbacks se leen; nunca se disparan. Consulta Modelo de seguridad.

El alcance de esa garantía merece decirse con precisión, porque es el tipo de frase que un equipo de seguridad va a verificar: el token que tiene el Agent solo escribe lo que está en la tabla de arriba, y cada escritura pasa por la confirmación descrita abajo. Fuera de eso, nada en tus fuentes. Y WhyStack no abre pull requests por ninguna vía: el rechazo de arriba es del producto, no solo del Agent.

El gate confirmed, en dos capas

Toda escritura requiere confirmación explícita, y la confirmación se verifica dos veces, en lados distintos de la frontera.

Capa 1: control-plane. La tool recibe un parámetro confirmed. Con confirmed: false (el valor por defecto) devuelve una vista previa y no toca nada: el canal, el texto, el ticket que se crearía. Solo confirmed: true ejecuta.

Capa 2: tu Agent. La confirmación viaja por el protocolo junto con la llamada. El Agent que corre en tu infra se niega a ejecutar cualquier operación marcada como escritura en el catálogo si la confirmación no está, y responde op_not_authorized.

La segunda capa existe para que no tengas que depender de la primera

La capa 1 es nuestra: tendrías que confiar en que la respetamos. La capa 2 corre dentro de tu infraestructura, en el mismo punto que ya rechaza cualquier operación fuera del catálogo. Un control-plane comprometido, con bugs o desactualizado no evade la segunda.

Quién tiene permiso

Dos verificaciones independientes, ambas antes de cualquier efecto:

• El permiso mcp:write: lo tienen owner y admin. Un token cuyo propietario es member no escribe; un token sin propietario (CLI, o heredado) nunca escribe. Esta es la que es fail-closed. Un usuario inactivo, un rol que no se resuelve, un error de consulta: todos niegan la escritura en lugar de permitirla.
• El alcance del token: un token read bloquea la escritura aunque su propietario tenga el rol owner. Es una restricción encima de la primera, no una segunda oportunidad: lo único que puede hacer es bloquear.

La matriz completa está en Tokens MCP. Ninguna de las dos verificaciones llega a tu infra: el rechazo ocurre en el control-plane, antes de que la llamada exista.

Auditoría con atribución

Toda escritura confirmada se convierte en un registro en el rastro de auditoría de tu organización, con el actor_id de la persona dueña del token, no “el agente”. Eso es lo que hace que la autonomía sea auditable en lugar de anónima, y está visible en Gobernanza.

El registro tiene dos fases, y el orden es deliberado:

1. Antes del efecto se registra la intención, y esto es fail-closed: si no se puede registrar, la escritura no ocurre. La política exige rastro para toda escritura confirmada, y una escritura sin rastro sería peor que una escritura que falló.
2. Después del efecto se registra el resultado (éxito o falla), y ese es best-effort: el efecto ya ocurrió, y una falla de registro aquí no puede deshacerlo.

Lo que entra en el rastro son metadatos: la acción, el destino, la longitud del texto, si hubo redacción. No el contenido en bruto.

Redacción del texto que compone el modelo

La redacción canónica de PII ocurre en el borde del Agent, antes de que cualquier dato salga de tu infra (consulta Redacción de PII). Pero el texto de un mensaje de Slack lo compone el modelo. No vino de ahí, así que no pasó por ahí.

De ahí una segunda pasada, de alta confianza, sobre el texto que la tool está por enviar: los ARNs, las direcciones de correo electrónico y las claves de acceso de AWS se enmascaran antes de que salga. La vista previa muestra el texto ya redactado (lo que apruebas es lo que sale), y el rastro registra que hubo redacción.

Lo que deliberadamente no enmascara: IPs, UUIDs y hashes de commit. Son la evidencia que hace útil el mensaje durante un incidente, y enmascararlos convertiría el registro en algo que nadie puede usar.

Las dos escrituras automáticas

Hay exactamente dos situaciones en las que WhyStack escribe sin que alguien lo pida en ese momento, y un cliente que lo descubre por su cuenta tiene razón en desconfiar. Así que:

Cuándo	Qué hace
Cambia la salud de las integraciones de tu flota (o se conecta un Agent nuevo)	Publica una línea en Slack con el nuevo estado
Concluye una investigación automática de incidente	Publica el diagnóstico en Slack

Ambas usan post_slack_message con la confirmación ya dada, y ambas comparten el mismo límite duro: solo informan. Nunca una acción correctiva, nunca un cambio en un sistema tuyo. Publicar el resultado de una lectura es la frontera, y no se mueve.

Ese límite no es una intención, y cada una lo sostiene de forma distinta: la investigación automática recibe una lista de tools sin ninguna de las cinco tools de escritura (el modelo que la conduce no tiene forma de pedirlas), y el aviso de salud de la flota no habla con tu entorno en absoluto: su única salida es una línea de texto hacia un canal.

Ambas, además, están desactivadas por defecto y solo ocurren con tres cosas ciertas a la vez: la funcionalidad habilitada en el proceso, un canal de Slack configurado y, para la salud de la flota, que tu organización haya optado por recibirla. Ambas se convierten en registros en el rastro, marcados con su propio origen (no como escritura del agente), así que lo que pidió una persona sigue siendo distinguible de lo que informó el sistema.

Dónde lo desactivas

Cuatro caminos, del más fino al más tosco:

1. Emite tokens read. Bloquea la escritura incluso para los owners, y es el valor por defecto del formulario.
2. No concedas mcp:write. Sin owner/admin, ningún token escribe.
3. No configures Jira/Slack en el Agent. Sin un connector que sirva esas operaciones, las tools ni siquiera aparecen para el modelo.
4. Niega por política. La denylist de tools rechaza las operaciones dentro de tu infra, sin importar lo que pida el control-plane.

Los dos primeros son controles nuestros; los dos últimos corren de tu lado de la frontera. Si tu evaluación de riesgo necesita una garantía que no dependa de nosotros, es el tercero o el cuarto.

Lo que esta página no cubre

• La lectura: Lo que lee el agente.
• Cómo se emite el token y cómo se define su alcance: Tokens MCP.
• Las seis operaciones de escritura del catálogo, y el enforcement dentro del Agent: Modelo de seguridad.