Agentes en Bitbucket Pipelines: permisos en el propio repo

Agentes en Bitbucket Pipelines, ahora con el MCP nuevo

En onext trabajamos con Bitbucket, así que esta novedad me toca de cerca. Atlassian ha conectado los agentes en Bitbucket Pipelines (lo que llaman Agentic Pipelines) a su MCP rediseñado, y lo que más me interesa no son las herramientas nuevas: es cómo se decide qué puede hacer el agente y dónde queda escrito.

Por si no lo conoces: Agentic Pipelines permite lanzar un agente como un paso más del pipeline, por ejemplo para revisar una PR, explicar un cambio o generar notas de versión. Puedes elegir entre Rovo Dev, Claude y Codex. La novedad del 23 de octubre aplica a Claude y Codex. Rovo Dev sigue con el MCP antiguo de momento.

Qué cambia

Según el anuncio de Atlassian, el MCP nuevo unifica herramientas de varios productos, así que el mismo agente puede, por ejemplo, detectar una vulnerabilidad en una PR y abrir un ticket en Jira para revisarla. Pero lo que yo quiero destacar es el modelo de permisos, que tiene tres capas.

1. Un token que dura lo que dura el paso

Para Bitbucket no gestionas tokens. Cada paso recibe un token OAuth de vida corta, limitado al repositorio del pipeline y que caduca cuando termina el paso. Por defecto solo puede leer el repo. Si el agente necesita más, lo declaras en bitbucket-pipelines.yml, bajo auth.system.scopes: escribir en el repo, leer o escribir PRs y leer o escribir en pipelines.

La propia documentación de seguridad lo dice claro: da el mínimo, usa scopes de lectura siempre que puedas y añade escritura solo en los pasos concretos que la necesiten.

Un matiz importante que cuentan en el anuncio: esos scopes se traducen a dos más amplios del MCP (uno de lectura y otro de escritura), y uno de ellos puede permitir más herramientas de lo que sugiere su nombre. Por eso existe la tercera capa.

2. Un token aparte para Jira y Confluence

Si quieres que el agente toque Jira o Confluence, necesitas un token de API con scopes, guardado en una variable llamada ATLASSIAN_MCP_API_TOKEN. Los scopes de ese token marcan lo que puede hacer. Si solo necesitas Bitbucket, la dejas vacía.

3. Reglas por herramienta

Esto es lo que más me gusta. Con permissions.on-ask decides, en el propio bitbucket-pipelines.yml, qué herramientas del MCP se aprueban y cuáles no, incluso operación por operación. Según la documentación de configuración, algo así deja al agente leer de Bitbucket y comentar en una PR, y nada más:

permissions:
  on-ask:
    default: deny
    allow:
      - "mcp__atlassian-v2-bitbucket-tools__executeRead"
      - "mcp__atlassian-v2-bitbucket-tools__executeWrite(name:addBitbucketRepoPullRequestComment)"
    deny:
      - "mcp__atlassian-v2-bitbucket-tools__executeDestructive"

Las reglas son sencillas: si coincide alguna de deny, se deniega; si no, si coincide alguna de allow, se aprueba; si no coincide ninguna, se aplica default. Una regla de deny siempre gana, aunque haya una de allow más específica.

Las letras pequeñas

Hay tres detalles que conviene tener claros antes de fiarse:

• Primero hay que configurar al agente para que pregunte. Las reglas solo actúan sobre las peticiones de permiso que llegan a Pipelines. Tienes que configurar Claude (en .claude/settings.json) o Codex (en .codex/config.toml) para que pidan permiso en esas herramientas. Si el agente ya las tiene aprobadas o bloqueadas por su cuenta, puede que la petición nunca llegue.
• Permitir una herramienta no da permisos de API. Lo que puede hacer el agente de verdad lo marcan los scopes y los tokens. Las reglas solo filtran encima.
• Denegar executeWrite no cierra todas las puertas. La documentación avisa de que otras herramientas o rutas también pueden escribir y hay que configurarlas aparte.

Y un consejo práctico: copia los identificadores de servidor de la documentación tal cual, porque las reglas distinguen mayúsculas y caracteres. Además, algunas herramientas del MCP antiguo todavía no están en el nuevo (por ejemplo, la que analiza fallos de un paso del pipeline). Si dependes de ellas, de momento puedes volver al antiguo con use-legacy-mcp: true, aunque Atlassian ya avisa de que retirará esa opción.

Por qué me parece la dirección correcta

En el post de permisos, sandboxes y secretos hablaba de permisos según el tipo de acción, secretos fuera del alcance del agente y entornos efímeros. Esto es exactamente eso, aplicado a CI/CD: el token vive lo que vive el paso, los permisos son mínimos por defecto y las reglas de qué puede hacer el agente están versionadas en el repo, junto al código. Si alguien quiere darle más poder al agente, tiene que cambiar un fichero versionado y, si tienes la rama protegida con revisiones obligatorias, pasar por una PR.

La documentación también recomienda combinarlo con protecciones de rama y revisiones obligatorias, para que lo que haga el agente siga pasando por una persona. Es el mismo enfoque que defiendo cuando hablamos de Spec-Driven Development: lo que importa se escribe, se versiona y se revisa.

Yo empezaría por un agente de solo lectura que resuma PRs, con default: deny, y ampliaría desde ahí.

Para cerrar

Si tu equipo está en Bitbucket y quiere meter agentes en sus pipelines con permisos bien atados desde el principio, en onext te ayudamos a diseñarlo. Escríbeme desde onext.es y lo hablamos.