Agent Harness

Ejecute Claude Code y Codex en su propia máquina bajo la política de su organización: tráfico de modelos gobernado, herramientas gobernadas, un único rastro de auditoría medido y sellado.

Nada del agente se traslada a la nube. Claude Code y Codex siguen ejecutándose en la máquina del desarrollador, con sus procesos, archivos, herramientas integradas y su bucle de agente. Lo que Sluis gobierna es el tráfico que sale: las peticiones al modelo y las llamadas a herramientas.

El cliente local se autentica ante Sluis con una clave de agente y habla con la entrada que corresponde a su protocolo: /agent/claude expone la API de Anthropic para Claude Code, /agent/codex/v1 expone la API Responses de OpenAI para Codex, /agent/cursor habla el protocolo Connect de Cursor sobre protobuf, y /agent/mcp es un punto MCP Streamable HTTP sin estado que transporta las herramientas gobernadas.

Claude Code y Codex son ejemplos, no una lista cerrada. Pi, T3 Code y cualquier cliente que acepte URL y clave de Anthropic Messages, OpenAI Responses o MCP usan el mismo Agent Harness.

Toda la configuración sigue un único orden, y cada paso necesita el anterior:

• 1. Conecte una suscripción. Claude o Codex, conectado una vez por cuenta de proveedor.
• 2. Cree una clave de agente. El secreto se muestra una sola vez, al crearlo.
• 3. Vincule la clave a esa cuenta. Una clave solo gasta las cuentas a las que está vinculada.
• 4. Configure el cliente local. La clave se guarda en SLUIS_AGENT_KEY, y la URL base apunta a /agent/claude para Claude Code, /agent/codex/v1 para Codex o /agent/cursor para Cursor, que lleva la misma clave en Authorization: Bearer.
• 5. Registre el punto de herramientas. Las herramientas solo llegan por /agent/mcp, registrado aparte: una URL base no añade ninguna.

Conectar una suscripción

Una organización conecta una o varias cuentas de suscripción de Claude y Codex en la vista Agent Harness. Claude se conecta con un token de claude setup-token; Codex, mediante la autorización de dispositivo de OpenAI. Sluis comprueba la credencial con el proveedor antes de guardar nada.

Claude: token de configuración

Necesita Claude Code instalado en su máquina y con sesión iniciada en una suscripción de Claude que permita peticiones al modelo.

• 1. Ejecute claude setup-token en una terminal. Imprime un token de larga duración, válido alrededor de un año, que empieza por sk-ant-oat.
• 2. Péguelo en el campo Claude de la Consola. El campo está enmascarado y el autocompletado está desactivado.
• 3. Al enviarlo, Sluis comprueba el token con Anthropic antes de guardar nada.
• 4. Un token comprobado queda sellado y cifrado en el vault de la pasarela. No se vuelve a mostrar, no se devuelve a ningún cliente y no se envía a ningún sitio salvo a Anthropic.

Un token que Anthropic no confirma se rechaza con un 422: no se crea ninguna cuenta, no se guarda nada y no se cobra nada. Reconectar la misma suscripción más tarde reutiliza la cuenta existente en lugar de añadir una segunda facturable.

Codex: autorización de dispositivo

Necesita un plan de ChatGPT que incluya Codex.

• 1. Inicie el acceso por dispositivo en la Consola. Sluis consulta a OpenAI y le muestra una URL de verificación y un código de usuario.
• 2. Abra esa URL con el botón, inicie sesión en OpenAI, escriba el código y apruebe. OpenAI puede pedir MFA.
• 3. La Consola consulta mientras usted aprueba. El intercambio ocurre en esta pestaña del navegador: salir de la página, o cambiar a otra pestaña de la vista, cancela el acceso y no guarda nada, igual que la acción Cancelar.
• 4. Tras la aprobación, Sluis guarda los tokens de acceso y de refresco cifrados en el vault de la pasarela y los renueva por usted; la rotación del token de refresco se serializa entre réplicas.

Un código de usuario caduca. Un flujo caducado informa expired y hay que empezarlo de nuevo, igual que una cuenta cuya credencial guardada OpenAI rechace más tarde: deja de servir hasta que alguien la reconecte.

Sluis cifra esas credenciales, las guarda en el vault de la pasarela y las renueva allí. Un token de proveedor nunca llega al cliente local, ni a los registros, ni a la auditoría, ni a las trazas: Claude Code y Codex solo tienen su clave de agente Sluis.

La conexión es autoservicio: un miembro puede añadir su propia suscripción. Propietarios y administradores ven todas las cuentas de la organización; un miembro solo ve y desconecta la suya.

Crear una clave de agente

Las claves de agente se crean en esa misma vista, aparte de sus claves API, porque los dos propósitos están aislados. Una clave de agente solo se autentica en /agent/*; una clave API ordinaria, solo en /v1/*. Cualquiera de las dos en la superficie equivocada da un 401, y el rechazo nunca revela el propósito de la clave.

El secreto se muestra una sola vez, al crearlo, y solo se guarda su hash. Cada clave se enruta por las cuentas de proveedor que usted le asigne, así que conectar la suscripción de un segundo miembro nunca reenruta una clave que ya funciona.

Una clave también registra el techo de la organización sobre las herramientas integradas del cliente local, escrito en la gramática de herramientas de Claude Code y validado al crearla. El cliente del desarrollador aplica esa lista en la máquina; Sluis nunca la lee durante una petición, de modo que nadie puede ampliar su propia clave, y una lista vacía simplemente no registra ningún techo.

Las herramientas que Sluis controla por sí mismo, en cada petición, son las herramientas MCP que expone: vea los plugins más abajo.

Apuntar los clientes a Sluis

Claude Code necesita una URL base y una credencial. Ponga ANTHROPIC_BASE_URL en la entrada Claude de esta pasarela y ANTHROPIC_API_KEY en la clave de agente que guarda en SLUIS_AGENT_KEY. La Consola genera el bloque de abajo con la URL pública de su pasarela ya rellenada.

Una URL base no añade herramientas: el protocolo de Anthropic no tiene descubrimiento de plugins, así que las herramientas solo llegan por un punto MCP que usted registra, con claude mcp add o una entrada .mcp.json. Ambos referencian ${SLUIS_AGENT_KEY} en lugar de la clave, para que ningún secreto acabe en un archivo versionado.

Codex lee su bloque de proveedor de ~/.codex/config.toml. Apunte base_url a la entrada Responses /agent/codex/v1, indique wire_api = "responses" y env_key = "SLUIS_AGENT_KEY", y añada el mismo punto MCP en [mcp_servers.sluis].

# the agent key is shown once, at creation: keep it in the environment
export SLUIS_AGENT_KEY='sluis-9f2c…'
export ANTHROPIC_BASE_URL='https://api.sluis.ai/agent/claude'
export ANTHROPIC_API_KEY="$SLUIS_AGENT_KEY"

# a base URL adds no tools: register the MCP endpoint separately
claude mcp add --transport http sluis 'https://api.sluis.ai/agent/mcp' \
  --header 'Authorization: Bearer ${SLUIS_AGENT_KEY}'

// .mcp.json: the same registration, kept with the project
{
  "mcpServers": {
    "sluis": {
      "type": "http",
      "url": "https://api.sluis.ai/agent/mcp",
      "headers": {
        "Authorization": "Bearer ${SLUIS_AGENT_KEY}"
      }
    }
  }
}

# Codex reads the key from SLUIS_AGENT_KEY, never from the config file
codex exec -m openai/gpt-5.4 'tighten the retry test'

# ~/.codex/config.toml
model = "openai/gpt-5.4"
model_provider = "sluis"

[model_providers.sluis]
name = "Sluis"
base_url = "https://api.sluis.ai/agent/codex/v1"
env_key = "SLUIS_AGENT_KEY"
wire_api = "responses"

[mcp_servers.sluis]
url = "https://api.sluis.ai/agent/mcp"
bearer_token_env_var = "SLUIS_AGENT_KEY"
default_tools_approval_mode = "approve"

Cursor apunta a la misma pasarela. Ponga su URL base en la entrada Cursor de esta pasarela, /agent/cursor, con la clave de agente en el encabezado Authorization. La ruta documentada es POST /agent/cursor/agent.v1.AgentService/Run, transportada por Connect con el tipo de contenido application/connect+proto. Un cliente que no pueda fijar una URL base puede apuntar al origen desnudo, porque el protocolo de Cursor fija una ruta absoluta.

Sluis recorre esas tramas Connect sin esquema y aplica el modo de protección de datos de la organización al texto del prompt que contienen: tokenize sustituye los valores detectados por marcadores reversibles y restituye los originales en la respuesta en streaming, mask los redacta sin más, block rechaza el turno antes de que nada llegue a Cursor, y una trama que Sluis no puede decodificar se rechaza en lugar de reenviarse. Solo allow_log la reenvía, y la pista de auditoría anota que no era inspeccionable.

Dos límites son propios de este transporte. El detector de nombres y la guarda contra inyección de prompt leen un cuerpo de petición JSON, y Connect protobuf no lo es: por eso no se ejecutan, la fila de auditoría los registra como no ejecutados, y una organización que hizo obligatoria la detección de nombres recibe un rechazo en lugar de un reenvío sin inspeccionar. El protocolo Connect tampoco informa del consumo de tokens, así que un turno de Cursor se sella en la pista de auditoría sin recuento de tokens.

Cada superficie acepta su credencial en una sola forma: x-api-key en la entrada Claude, que es lo que envían los clientes de Anthropic, y Authorization: Bearer en las entradas de Codex, Cursor y MCP. La misma clave en el otro encabezado se rechaza.

Plugins MCP

Las herramientas gobernadas llegan por un único punto sin estado, POST /agent/mcp. No guarda sesión: cada petición vuelve a derivar toda la cadena de autorización, así que revocar una clave, un plugin o una clave de firma surte efecto en la llamada siguiente.

Hay dos clases. Los plugins mantenidos por Sluis son código Sluis compilado, disponible para toda la organización, y no ejecutan código del cliente. Los plugins de organización son los suyos: un manifiesto TOML firmado con Ed25519.

Un manifiesto se acepta solo si su firma se verifica con una clave de firma inscrita por su organización, y es inmutable por (organisation, id, version): una definición de herramienta modificada es una versión nueva, nunca una edición silenciosa. Cada plugin queda fijado a un servidor MCP HTTPS gobernado, cuyo punto de acceso debe coincidir exactamente con la URL del manifiesto firmado.

El trabajo del operador son tres pasos. El propietario inscribe la clave de firma de la organización. Un propietario o administrador registra el manifiesto firmado contra un servidor MCP gobernado. Después el plugin se vincula a las claves de agente que pueden usarlo, y un plugin sin vínculos no se expone a nadie.

Las URL de servidor, los manifiestos, las firmas y las credenciales upstream nunca llegan a un cliente. Un desarrollador ve nombres de herramientas y esquemas, nada más.

Contexto y habilidades que inyecta la pasarela

Sus estándares de ingeniería solo son política si un desarrollador no puede olvidarlos. Un CLAUDE.md incorporado al repositorio es una sugerencia: puede editarse, borrarse o simplemente no leerse, y nada registra qué ocurrió. El mismo texto que la pasarela inserta en cada solicitud de agente gobernada es la decisión de la organización: escriba primero la prueba que falla, no añada dependencias sin un ADR aprobado, este repositorio contiene datos personales, así que pseudonimice antes de pegar. Es la mitad del harness que gobierna cómo trabaja un agente, no qué modelo ni qué herramientas puede alcanzar.

Dos tipos de plugin lo transportan, y ninguno concede capacidad propia:

• Contexto. Texto literal, inyectado antes del propio prompt del desarrollador, hasta 16 KiB por versión.
• Habilidad. Un nombre, sus instrucciones y los nombres de herramienta que espera. Esos nombres se intersecan con el techo de herramientas registrado en la clave: una habilidad declara lo que necesita y nunca puede ampliar una clave, así que una herramienta que el techo no incluye simplemente no se le menciona al modelo.

Una versión se vincula en uno de tres ámbitos, y cada solicitud resuelve los tres:

• Organización. Todas las claves de agente de la organización, incluidas las creadas después del vínculo. Es el ámbito para una regla que nadie debería tener que acordarse de adjuntar.
• Usuario. Todas las claves de agente de un miembro: un resumen de incorporación, o una postura más estricta para una sola persona.
• Clave. Una clave de agente exacta, que es lo que ya hacía un vínculo.

La resolución es determinista, porque el orden de inyección cambia el prompt. Sluis toma la unión de los tres ámbitos, vuelve a verificar cada plugin igual que para las herramientas, descarta versiones duplicadas y ordena primero la organización, luego el usuario y por último la clave: la regla general se lee primero y la excepción concreta al final. El contexto se inyecta literalmente; una habilidad, como sección con nombre. En la entrada de Claude los bloques se anteponen a system, en cualquiera de las dos formas que permite esa API; en la entrada de Codex, a instructions, o como instrucción developer inicial cuando la solicitud no lleva ninguna.

Todo lo inyectado en una solicitud cabe en 32 KiB. Por encima, la solicitud se rechaza con un 422 que nombra los plugins que rebasaron el límite. Nada se trunca en silencio: media instrucción es peor que ninguna, y una organización que cree que una regla está en vigor tiene que enterarse cuando no lo está.

El texto inyectado no lo reescribe la protección de datos, y el orden es de una sola dirección: primero se analiza y pseudonimiza el prompt del desarrollador, y después se antepone su política. Estos bloques son su propio contenido gobernado, redactado en su propia Consola, así que no hay nadie de quien haya que protegerlos, y tokenizarlos destruiría lo que dicen. “Escale a security@example.com antes de pegar” convertido en “escale a «EMAIL_1» antes de pegar” ya no es una instrucción que nadie pueda seguir.

Estos dos tipos se redactan en la Consola y no llevan firma. Una firma existe para impedir que un manifiesto apunte una credencial gobernada a un endpoint que nadie aprobó; un bloque de texto no apunta a nada. Todo lo demás que hace fiable un registro sigue vigente: una versión es inmutable, sus bytes exactos se hashean y la fila registra quién la escribió y cuándo. Un manifiesto con una entrada MCP conserva la firma obligatoria y la comprobación del firmante inscrito en cada solicitud. La pestaña Plugins muestra cuál de los dos es cada versión, de modo que «redactado en la Consola» es un hecho declarado y no un campo ausente, y previsualiza los bloques resueltos en el orden en que la pasarela los inyecta para una clave o un miembro elegidos.

Cada bloque inyectado deja una marca en la fila de auditoría sellada, context:<plugin_id>@<version>#<digest8>, donde el resumen son los ocho primeros caracteres del hash de esa versión. Como una versión es inmutable, la marca basta para reconstruir el texto exacto entregado al modelo: la traza de auditoría por sí sola responde si un agente estaba sujeto a una regla dada en el momento de actuar.

Cursor es la carencia declarada. Su transporte /agent/cursor es un esquema binario propietario: Sluis sabe encontrar y reescribir el texto dentro de esas tramas —así funciona allí la protección de datos—, pero no puede saber qué campo es el prompt de sistema, y escribir en un campo adivinado corrompería la solicitud en lugar de gobernarla. Por eso no se inyecta nada en esa entrada, y un turno de Cursor lleva su contexto solo si el cliente del propio desarrollador lo envía. La vista previa de la Consola dice lo mismo.

La gobernanza que sigue aplicando

El tráfico de agente es tráfico Sluis ordinario, con una excepción. La pseudonimización y el DLP se ejecutan antes del envío, también dentro de las tramas protobuf de Cursor, los límites de tasa y presupuesto de la clave se aplican por petición, las herramientas MCP se autorizan llamada por llamada, y cada llamada a modelo y a herramienta se audita y se mide. La excepción es la residencia: en el plano de agentes la política se registra, no se aplica, por el motivo del aviso al principio de esta página.

Son las mismas reglas descritas en Protección de datos y Presupuestos y caché, y son política de la organización: una clave de agente no puede relajarlas.

Facturación

Cada cuenta de proveedor activa gestionada por Sluis cuesta 16,50 € de precio de lista por mes natural, cobrada como máximo una vez por cuenta y mes. Se factura a su raíz de facturación de nivel superior y aparece como su propia línea de factura, separada del uso medido. El IVA y el recargo por método de pago se aplican igual que en el resto de la factura.

Desconectar una cuenta detiene los meses siguientes. Reconectar la misma suscripción upstream reutiliza la cuenta existente en lugar de añadir una segunda facturable, así que desconectar y reconectar dentro del mismo mes se cobra una vez.

El uso de la pasarela sigue facturándose por consumo, igual que con las claves API.

Disponibilidad

La vista Agent Harness aparece en la Consola en cuanto el indicador de despliegue agent_harness está activado para su organización. Pídanos activarlo si no la ve.

Resolución de problemas