MCP no Kiro: como conectar ferramentas, Powers e contas AWS ao agente com permissão mínima

O Model Context Protocol (MCP) é o padrão aberto que liga o Kiro, a IA agêntica da AWS para desenvolvimento de software, a ferramentas e dados externos. Cada servidor MCP amplia o que o agente consegue ler e fazer, então cada um entra com permissão mínima: credencial de curta duração, política de leitura, regra que nega ferramentas de escrita e lista de servidores aprovados pela organização.

Verificado contra a documentação de MCP, Powers e governança do Kiro na atualização de 15/10/2026. Campos de configuração e controles administrativos mudam entre versões: confira na versão instalada.

A definição oficial descreve o MCP como "um padrão de código aberto para conectar aplicações de IA a sistemas externos", com a analogia de uma porta USB-C para IA. A analogia ajuda a entender o encaixe e esconde o risco: o que você pluga nessa porta passa a agir com a sua identidade. Um servidor MCP local é um processo na estação do desenvolvedor, com acesso aos recursos da conta de usuário dele; um servidor remoto recebe as perguntas do agente e devolve conteúdo que o modelo lê como contexto. Configurar MCP no Kiro, portanto, é uma decisão de segurança antes de ser uma decisão de produtividade.

A adoção segura segue uma ordem: configurar o primeiro servidor, isolar ferramentas em agentes, empacotar contexto com Powers, ligar uma conta AWS só com leitura e, por fim, governar a lista de servidores da organização.

Onde configurar o MCP no Kiro

O Kiro lê a configuração de MCP em dois níveis, conforme a documentação de configuração:

• Workspace: .kiro/settings/mcp.json, vale só para o projeto aberto e pode ser versionado com o repositório.
• Usuário: ~/.kiro/settings/mcp.json, vale para todos os workspaces daquela pessoa.

Os dois arquivos se combinam e o workspace prevalece. Quando o mesmo nome de servidor aparece em mais de um lugar, a ordem de prioridade é: campo mcpServers de um agente personalizado, depois o workspace, depois o usuário. A definição de maior prioridade substitui a outra por inteiro, e "disabled": true numa fonte de prioridade maior impede o servidor de subir. Esse detalhe é útil para governança: o mcp.json versionado do repositório de produção consegue desligar, pelo nome, um servidor que alguém deixou ativo na configuração pessoal.

Para abrir os arquivos, use a paleta de comandos (Cmd + Shift + P no Mac, Ctrl + Shift + P no Windows e no Linux) com Kiro: Open workspace MCP config (JSON) ou Kiro: Open user MCP config (JSON). O exemplo literal da página de MCP do Kiro sobe um servidor local com uvx:

{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"],
      "disabled": false
    }
  }
}

Servidores remotos usam url no lugar de command. A documentação exige HTTPS (HTTP só para localhost) e informa que servidores remotos por HTTP e SSE funcionam no IDE, na CLI e na versão web. Segredo nunca fica escrito no arquivo: a referência usa a sintaxe ${VARIAVEL}, e o Kiro só expande variáveis aprovadas na configuração Mcp Approved Env Vars; variável não aprovada gera aviso.

{
  "mcpServers": {
    "docs-internas": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${DOCS_MCP_TOKEN}"
      },
      "autoApprove": ["buscar_documento"],
      "disabledTools": ["publicar_documento"]
    }
  }
}

Dois campos desse exemplo pedem critério. autoApprove dispensa a confirmação de cada chamada e aceita "*" para aprovar todas as ferramentas do servidor; use só em ferramenta de leitura. disabledTools esconde a ferramenta do agente de forma permanente, o que é o jeito certo de tirar do alcance uma operação de escrita que o servidor oferece e o time não precisa.

Token fixo em cabeçalho é o caminho mais simples e costuma ser o de credencial com vida mais longa. Quando o servidor remoto exige OAuth, a documentação de configuração descreve o campo oauth. Na maioria dos servidores, o registro dinâmico de cliente (Dynamic Client Registration) dispensa configuração: o Kiro conecta e abre a página de autorização. Se o provedor de identidade da empresa exige um cliente pré-registrado, informe clientId e um redirectUri de loopback (http em 127.0.0.1 ou localhost) igual ao cadastrado no provedor:

{
  "mcpServers": {
    "docs-internas": {
      "url": "https://mcp.example.com/mcp",
      "oauth": {
        "clientId": "kiro-docs-internas",
        "redirectUri": "http://127.0.0.1:PORTA/callback"
      },
      "autoApprove": ["buscar_documento"]
    }
  }
}

Dois detalhes evitam retrabalho. clientSecret só faz sentido junto com clientId, e a documentação informa que o IDE aceita apenas clientes públicos, sem segredo; o cliente confidencial é suportado no CLI. E o emissor (issuer) publicado nos metadados do servidor de autorização precisa bater exatamente com a URL anunciada, incluindo esquema, host, porta, caminho e barra final, como alerta a seção de solução de problemas da mesma página. Uma barra a mais no fim da URL já faz a autorização falhar.

Alguns diretórios de servidores oferecem instalação por link no esquema kiro://. Abrir o link não muda nada sozinho: o Kiro mostra uma tela de confirmação com o comando, os argumentos e os nomes das variáveis de ambiente e dos cabeçalhos, sem os valores. Essa tela é o momento de ler o comando com a mesma atenção que você daria a um script baixado da internet, porque é exatamente isso que ele é.

Quando o servidor não aparece

Ao salvar o mcp.json, os servidores reconectam sozinhos. O estado de cada um fica na aba MCP servers do painel do Kiro, e os registros detalhados ficam no painel Output, na opção Kiro - MCP Logs. A página de MCP lista os motivos pelos quais uma ferramenta é excluída mesmo com o servidor conectado:

• Nome com mais de 64 caracteres, contando o prefixo do servidor. Nome de servidor longo no mcp.json consome esse limite de todas as ferramentas dele; prefira nomes curtos, como eks e cloudwatch.
• Caracteres inválidos no nome. O nome precisa casar com ^[a-zA-Z][a-zA-Z0-9_]*$.
• Descrição vazia.

Descrição de ferramenta acima de 10.000 caracteres não exclui a ferramenta, mas gera aviso: ela continua funcionando e pode deixar as respostas mais lentas, segundo a mesma página. Fora da lista de exclusões, as causas que a documentação de configuração aponta são JSON inválido, comando fora do PATH (rode o comando direto no terminal para confirmar) e variável de ambiente ausente, com nome errado ou fora da lista Mcp Approved Env Vars.

MCP dentro de agentes personalizados

Configurar servidores no mcp.json deixa as ferramentas disponíveis para o agente padrão. Para tarefas sensíveis, o desenho mais seguro é um agente personalizado que enxerga só o que a tarefa exige. Agentes do workspace ficam em .kiro/agents/, em JSON ou Markdown, vão para o controle de versão e só carregam quando o workspace é marcado como confiável.

Três campos fazem o recorte de ferramentas, conforme a referência de configuração:

• includeMcpJson: quando verdadeiro, o agente recebe também os servidores do mcp.json do usuário e do workspace. Para um agente restrito, declare false e defina os servidores no próprio arquivo, em mcpServers.
• tools: lista de seletores. read, write e shell são categorias de ferramentas nativas; @servidor inclui todas as ferramentas de um servidor MCP; @servidor/ferramenta inclui uma só; @mcp inclui todas as ferramentas MCP; "*" inclui tudo.
• permissions: regras por capacidade (capability), com padrões (match) e efeito (allow, ask ou deny). Para a capacidade mcp, os padrões são nomes de servidor e de ferramenta.

O exemplo abaixo é um agente ops-leitura para perguntas sobre a operação na AWS. Ele usa dois servidores do repositório awslabs/mcp: o Amazon CloudWatch MCP Server e o Amazon EKS MCP Server, que, segundo o próprio repositório, roda em modo somente leitura por padrão e só libera operações de mutação com a opção --allow-write.

{
  "name": "ops-leitura",
  "description": "Responde perguntas sobre a operação AWS usando só ferramentas de leitura.",
  "prompt": "Responda em português. Consulte apenas dados de leitura. Se a resposta exigir uma mudança no ambiente, descreva a mudança como pull request ou chamado, sem executá-la.",
  "includeMcpJson": false,
  "mcpServers": {
    "cloudwatch": {
      "command": "uvx",
      "args": ["awslabs.cloudwatch-mcp-server@X.Y.Z"],
      "env": { "AWS_PROFILE": "ops-leitura", "AWS_REGION": "sa-east-1" }
    },
    "eks": {
      "command": "uvx",
      "args": ["awslabs.eks-mcp-server@X.Y.Z"],
      "env": { "AWS_PROFILE": "ops-leitura", "AWS_REGION": "sa-east-1" }
    }
  },
  "tools": ["read", "@cloudwatch", "@eks"],
  "permissions": {
    "rules": [
      { "capability": "mcp", "match": ["cloudwatch/*", "eks/list_*", "eks/get_*", "eks/search_*"], "effect": "allow" },
      { "capability": "mcp", "match": ["eks/apply_yaml", "eks/manage_*", "eks/add_inline_policy", "eks/generate_app_manifest"], "effect": "deny" }
    ]
  }
}

As decisões por trás de cada linha:

• Sem write nem shell em tools. O agente lê arquivos do repositório, mas não edita nem executa comando. Quem precisa mudar algo usa outro agente, com outro escopo.
• Versão fixada no lugar de @latest. X.Y.Z é a versão que o time testou. Com @latest, cada inicialização pode trazer um servidor com ferramentas novas que ninguém revisou.
• Deny explícito mesmo com o servidor em modo leitura. Se alguém acrescentar --allow-write nos argumentos, a regra continua bloqueando. O custo do deny em eks/manage_* é perder também as leituras dessas ferramentas; para perguntas de operação, list_k8s_resources cobre a maior parte.
• Leitura de log fora do padrão. No EKS MCP Server, get_pod_logs, get_k8s_events, get_cloudwatch_logs, get_eks_vpc_config e get_eks_insights exigem --allow-sensitive-data-access, a mesma opção que libera a leitura de Secrets do Kubernetes. Sem ela, o agente não lê log de aplicação, que é onde dado pessoal costuma aparecer. Ligue só para clusters sem dado de cliente, decididos antes, porque a opção vale para o servidor inteiro.

Com o agente pronto, a qualidade da resposta depende de como a solicitação é escrita. Uma solicitação de operação bem formada delimita o recurso, a janela de tempo e o formato da saída, e já diz o que fazer quando a resposta pedir mudança:

Cluster: eks-homologacao, namespace: pagamentos.
Janela: últimas 6 horas.

1. Liste os pods do namespace com reinício na janela.
2. Liste os alarmes do CloudWatch em estado ALARM ligados a esse serviço.
3. Cruze os dois: quais reinícios coincidem com qual alarme.

Formato da resposta:
- Tabela de pods: nome, reinícios, último estado.
- Tabela de alarmes: nome, métrica, horário da mudança de estado.
- Hipótese de causa, marcada como hipótese, com a evidência que a sustenta.
- Ferramentas chamadas, na ordem.
Se a correção exigir mudança no ambiente, descreva como pull request.

A resposta esperada é um relatório de leitura: tabelas montadas a partir de list_k8s_resources e das ferramentas de alarme do CloudWatch, uma hipótese separada dos fatos e, se for o caso, a descrição de uma mudança para revisão. A linha "ferramentas chamadas" é o que permite conferir o caminho do agente; se ele tentar apply_yaml para "corrigir" um manifesto, o deny bloqueia e o bloqueio aparece na sessão. Repare que a solicitação usa o cluster de homologação: o mesmo agente só aponta para produção depois que o time revisou algumas respostas e as chamadas registradas no AWS CloudTrail.

Um detalhe que muda o desenho: a documentação de permissões informa que o permissions.yaml de escopo de workspace fica em ~/.kiro/workspace-roots/<hash>/permissions.yaml, fora do repositório. Regra que precisa valer para o time inteiro vai, portanto, dentro do arquivo do agente, que é versionado e revisado em pull request.

Powers: ferramentas com contexto sob demanda

A documentação de Powers define o recurso assim: Powers dão ao agente acesso imediato a conhecimento especializado sobre uma tecnologia. Na prática, um Power empacota três coisas:

• plugin.json (obrigatório): o manifesto, com nome, versão, autor e as palavras-chave que ativam o Power.
• skills/<nome>/SKILL.md: instruções da tarefa, com scripts e material de referência opcionais na mesma pasta.
• mcp.json (opcional): os servidores MCP que o Power traz.

Powers criados no formato original, com POWER.md, continuam funcionando; a documentação recomenda o formato de plugin para Powers novos. O manifesto segue o esquema publicado na página de criação de Powers:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "operacao-aws-leitura",
  "version": "1.0.0",
  "description": "Consulta de métricas, alarmes e clusters com perfil só de leitura",
  "author": { "name": "Time de Plataforma" },
  "keywords": ["alarme", "cloudwatch", "cluster", "pod", "métrica"],
  "license": "Apache-2.0"
}

A diferença para o MCP configurado direto está no momento em que as ferramentas entram no contexto. Um servidor no mcp.json expõe todas as ferramentas desde o início da sessão. Um Power fica parado até a conversa mencionar uma das palavras-chave; aí o Kiro carrega as instruções e as ferramentas daquele Power. A documentação descreve o efeito como redução do uso de contexto de base, o que também diminui a chance de o agente escolher uma ferramenta que não tinha nada a ver com a tarefa.

Para governança, Powers são mais uma origem de servidores MCP e entram no mesmo controle: a capacidade power existe nas regras de permissão, o campo includePowers decide se um agente personalizado os recebe e o seletor @powers alcança as ferramentas de Powers nos hooks. Instalar um Power de terceiros pede a mesma leitura do mcp.json que ele carrega.

Uma desambiguação que evita confusão em reunião de compras: Powers, o recurso descrito aqui, não tem relação com Power, um dos planos de assinatura listados na página de preços do Kiro.

O Kiro na conta AWS só com leitura

O caso de uso mais sensível é deixar o agente consultar a conta AWS: "quais pods estão reiniciando?", "que alarme disparou à noite?", "qual serviço puxou o custo do mês?". O padrão descrito no exemplo de escopo Kiro na operação com perfil somente leitura tem cinco camadas, e a primeira é a que de fato decide: o servidor MCP chama as APIs com a credencial do perfil, então a permissão do agente é a permissão do perfil.

1. Credencial de curta duração pelo IAM Identity Center

Nada de chave de acesso de longa duração no notebook. O AWS IAM Identity Center entrega credenciais temporárias por um conjunto de permissões (permission set) dedicado ao agente. A sessão tem duração padrão de 1 hora e máxima de 12 horas, e a própria AWS recomenda não passar do necessário. O perfil nomeado é o mesmo que aparece no AWS_PROFILE do agente:

[profile ops-leitura]
sso_session = empresa
sso_account_id = 111122223333
sso_role_name = KiroOpsLeitura
region = sa-east-1

[sso-session empresa]
sso_start_url = https://empresa.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

2. Política de leitura, com o trade-off de cada uma

As duas políticas gerenciadas candidatas parecem equivalentes pelo nome e não são:

• ViewOnlyAccess concede, nas palavras da AWS, permissão para ver recursos e metadados básicos. Ela lista buckets, mas não lê objetos; descreve grupos de log, mas não lê eventos; lê métricas do CloudWatch; e não inclui ações do Cost Explorer.
• ReadOnlyAccess lê conteúdo: s3:Get*, dynamodb:Scan e dynamodb:Query, logs:Get* e logs:StartQuery, ssm:Get*. Inclui também sqs:Receive*, e receber uma mensagem a deixa invisível para os consumidores durante o tempo limite de visibilidade: uma "leitura" que interfere na aplicação.

Para um agente, ReadOnlyAccess é acesso a dado de cliente, com todas as consequências de LGPD. O ponto de partida que recomendamos é ViewOnlyAccess no conjunto de permissões, mais uma política em linha só com as leituras que a tarefa pede. Para perguntas de custo, por exemplo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LeituraDeCusto",
      "Effect": "Allow",
      "Action": [
        "ce:GetCostAndUsage",
        "ce:GetCostForecast",
        "ce:GetDimensionValues"
      ],
      "Resource": "*"
    }
  ]
}

Para os servidores MCP gerenciados pela AWS, há uma camada extra no IAM. O AWS Security Blog descreve duas chaves de condição: aws:ViaAWSMCPService, verdadeira quando a solicitação chega por um servidor MCP gerenciado, e aws:CalledViaAWSMCP, com o nome do servidor (por exemplo, aws-mcp.amazonaws.com). Com elas, uma SCP nega qualquer ação feita por esse caminho numa unidade organizacional inteira, como a de produção com dado pessoal:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllActionsViaMCP",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Bool": { "aws:ViaAWSMCPService": "true" }
      }
    }
  ]
}

Essas chaves valem para solicitações que passam por um servidor MCP gerenciado pela AWS. Servidores locais do awslabs chamam as APIs direto, com a credencial do perfil, e para eles o controle continua sendo a política do conjunto de permissões. O AWS MCP Server, gerenciado e com disponibilidade geral anunciada em 6 de maio de 2026, atende pelas regiões Leste dos EUA (Norte da Virgínia) e Europa (Frankfurt): quando as respostas puderem conter dado pessoal, esse fluxo entra no registro das operações de tratamento.

3. Servidores oficiais, em modo leitura

Prefira os servidores do repositório awslabs/mcp e do AWS MCP Server a implementações de origem desconhecida, e confira o modo de cada um. O próprio repositório informa que o Agent Toolkit for AWS é o sucessor dos servidores, plugins e skills publicados no AWS Labs e o indica para uso em produção; para um ambiente novo, comece por ele. O EKS MCP Server local já nasce em leitura. Para servidores gerenciados acessados pelo MCP Proxy for AWS, a opção --read-only desliga as ferramentas que podem exigir escrita, com base na anotação readOnlyHint. É um filtro no cliente: o limite real continua sendo o IAM. O Amazon EKS MCP Server gerenciado, em preview, separa as permissões no próprio IAM, conforme a referência de configuração do EKS MCP Server: eks-mcp:InvokeMcp para inicializar e listar ferramentas, eks-mcp:CallReadOnlyTool para as ferramentas de leitura e eks-mcp:CallPrivilegedTool para as de escrita. Para o agente de leitura, conceda as duas primeiras e deixe a terceira fora do conjunto de permissões.

4. Regra deny para ferramentas de escrita

No Kiro, a precedência é deny > ask > allow, e um deny em qualquer escopo bloqueia a ação mesmo com allow em outro lugar. Além das regras do agente, vale uma base pessoal em ~/.kiro/settings/permissions.yaml, que acompanha o desenvolvedor em todos os projetos:

rules:
  # Nega, em qualquer servidor, ferramentas com verbo de escrita no nome
  - capability: mcp
    match: ["*/delete_*", "*/create_*", "*/update_*", "*/put_*", "*/apply_*"]
    effect: deny
  # O resto das ferramentas MCP pede confirmação
  - capability: mcp
    match: ["*"]
    effect: ask

A regra por nome é uma rede, não uma garantia: ferramenta de escrita com nome neutro passa por ela. Por isso ela vem depois do IAM e da lista de ferramentas do agente, nunca no lugar deles.

5. Hook Pre Tool Use como segunda verificação

O gatilho Pre Tool Use dispara antes de cada chamada de ferramenta, e o seletor @mcp alcança todas as ferramentas MCP, conforme a documentação de tipos de hook. Há dois tipos de ação, com força diferente: a ação de agente envia uma instrução ao agente, e a ação de comando pode bloquear a chamada. Para bloquear, use o código de saída 2. A referência de códigos de saída o define como bloqueio em PreToolUse, com o STDERR devolvido ao modelo, e trata os demais códigos diferentes de zero como falha do hook, exibida como aviso. A documentação de ações descreve bloqueio para qualquer saída diferente de zero nesse gatilho. As duas páginas divergem nos outros códigos e concordam no 2, então o 2 é o único valor que bloqueia nas duas leituras. O arquivo segue o esquema v1 descrito no guia de hooks da IDE 1.0 (version, hooks[].name, trigger, matcher e action com type igual a agent ou command) e usa os dois tipos de ação:

{
  "version": "v1",
  "hooks": [
    {
      "name": "Conferir leitura antes de toda chamada MCP",
      "trigger": "PreToolUse",
      "matcher": "@mcp",
      "action": {
        "type": "agent",
        "prompt": "Antes de chamar esta ferramenta, confirme que ela só consulta dados. Se ela cria, altera ou apaga recurso, não chame: descreva a mudança como pull request."
      }
    },
    {
      "name": "Bloquear ferramentas de escrita do EKS",
      "trigger": "PreToolUse",
      "matcher": "^mcp_eks_(apply_yaml|manage_k8s_resource|manage_eks_stacks|add_inline_policy|generate_app_manifest)$",
      "action": {
        "type": "command",
        "command": "echo 'Ferramenta de escrita bloqueada neste workspace: proponha a mudança como pull request.' >&2; exit 2"
      }
    }
  ]
}

O primeiro hook é uma instrução, útil para reforçar o comportamento, mas sujeito à interpretação do modelo e com custo de contexto em cada chamada. O segundo é um bloqueio determinístico. O matcher aceita seletores como @eks/apply_yaml, um por ferramenta; para cobrir várias ferramentas num único hook, o exemplo usa expressão regular sobre o ID interno mcp_<servidor>_<ferramenta>, que é a forma documentada na página de tipos de hook para casar ferramentas MCP por regex. As âncoras ^ e $ evitam que o padrão case por acaso com ferramentas de outro servidor que contenham o mesmo texto. A saída 2 impede a execução e devolve a mensagem ao agente. Antes de confiar no bloqueio, confirme o ID que a ferramenta recebe no seu ambiente com um hook temporário que grava o payload do evento. Esse hook de captura, o desenho completo de hooks, os eventos de arquivo e as verificações antes de tarefa estão no post sobre hooks no Kiro.

Governança de MCP na organização

Configuração por desenvolvedor não escala para o time inteiro. Para usuários enterprise do Kiro, o administrador controla o MCP pelo console do Kiro na AWS, em Settings > Shared settings, com duas opções descritas na documentação de governança de MCP:

• Desligar o MCP. O cliente suprime todos os servidores. O comportamento é de falha fechada: se o cliente não alcança a API de governança, o MCP fica desligado até a reconexão.
• Publicar um registry com a lista de servidores aprovados. O administrador informa a URL de um arquivo JSON no campo MCP Registry URL.

O arquivo tem um array servers. Cada entrada traz name, description e version, e usa uma de duas formas: remotes, com exatamente uma entrada do tipo streamable-http ou sse; ou packages, com exatamente uma entrada de registryType npm, pypi ou oci e transporte stdio. A máquina do desenvolvedor precisa ter o executor correspondente instalado (npx, uvx ou docker).

{
  "servers": [
    {
      "server": {
        "name": "docs-internas",
        "description": "Busca na documentação interna de arquitetura",
        "version": "1.0.0",
        "remotes": [
          { "type": "streamable-http", "url": "https://mcp.example.com/mcp" }
        ]
      }
    },
    {
      "server": {
        "name": "cloudwatch",
        "description": "Amazon CloudWatch MCP Server, perfil só de leitura",
        "version": "X.Y.Z",
        "packages": [
          {
            "registryType": "pypi",
            "identifier": "awslabs.cloudwatch-mcp-server",
            "transport": { "type": "stdio" }
          }
        ]
      }
    }
  ]
}

As regras de operação que a documentação define:

• O arquivo é servido por HTTPS, de qualquer servidor web (inclusive um bucket do Amazon S3 ou uma URL só da rede corporativa), com certificado assinado por autoridade certificadora confiável. Certificado autoassinado não é aceito.
• O Kiro busca o registry na inicialização e depois a cada 24 horas. Servidor instalado que sai da lista é encerrado e não pode ser adicionado de novo; servidor com versão diferente da lista é reiniciado na versão do registry.
• URL e identificador do pacote ficam somente leitura para o usuário, que ainda pode acrescentar variáveis de ambiente, cabeçalhos, tempo limite e permissões de confiança das ferramentas.
• A política vale por organização ou por conta, e a da conta prevalece. O exemplo da própria documentação: MCP desligado na organização e lista aprovada liberada para times específicos.

O limite precisa estar no documento de risco, porque a própria documentação o declara: o desligamento e o registry são aplicados no cliente, e um usuário com acesso de administrador na máquina consegue contorná-los. Os controles da organização também não valem para quem entra com Builder ID ou login social, só para quem entra com IAM Identity Center ou chave de API. A governança do Kiro, portanto, completa o IAM e a gestão da estação de trabalho, sem substituí-los. O tema volta, com trilha de auditoria e revisão humana, no post sobre governança de IA no código.

Riscos de MCP e como mitigar

O conteúdo que uma ferramenta devolve é entrada não confiável. Um comentário num ticket, uma página web buscada ou uma descrição de recurso pode conter instruções escritas para o modelo, e o agente as lê no mesmo contexto das suas. É a injeção de prompt indireta, primeiro item do OWASP Top 10 para aplicações com LLM (LLM01:2025 Prompt Injection), que na lista convive com LLM06:2025 Excessive Agency, o agente com mais capacidade do que a tarefa exige. A defesa não é ensinar o modelo a desconfiar; é garantir que, se ele obedecer à instrução errada, não tenha permissão para causar dano.

Duas observações da página de boas práticas de MCP do Kiro merecem destaque. O Kiro não verifica servidores de terceiros: a responsabilidade de revisar o código é de quem instala. E separar servidores por workspace organiza a lista sem isolar o acesso: um servidor stdio roda como processo local com os recursos da conta do usuário. A configuração mcpSandboxing aplica a sandbox de comandos locais a servidores stdio e não alcança servidores remotos.

Checklist de MCP para o time

1. Inventário: cada servidor MCP em uso tem dono, finalidade, origem e versão registrados.
2. Origem: só repositórios oficiais ou código revisado pelo time; nada instalado direto de link sem ler o comando.
3. Versão: fixada nos argumentos e no registry; atualização entra por pull request.
4. Credencial: conjunto de permissões dedicado no IAM Identity Center, sessão curta, nenhuma chave de acesso de longa duração na estação.
5. Política: ViewOnlyAccess mais leituras específicas; ReadOnlyAccess só com justificativa e análise de dado pessoal.
6. Ferramentas: agente personalizado com includeMcpJson falso e seletores explícitos em tools.
7. Regras: deny para escrita no arquivo do agente e no permissions.yaml do usuário; autoApprove só em leitura.
8. Hooks: Pre Tool Use com bloqueio por comando para as ferramentas que não podem rodar.
9. Segredos: só por ${VAR} aprovada; arquivos de configuração com credencial fora do Git.
10. Organização: registry publicado por HTTPS, política por conta para o time que precisa e MCP desligado onde não precisa.
11. Auditoria: chamadas às APIs conferidas no AWS CloudTrail no primeiro dia de uso.
12. Convenção: regras de uso do agente registradas em arquivos de steering do repositório.

Para quem ainda está escolhendo como introduzir o Kiro no time, o post Kiro, a IA agêntica da AWS para desenvolvimento de software cobre o panorama, e o post sobre IAM e Zero Trust na AWS aprofunda conjuntos de permissões, SCPs e privilégio mínimo, que são a base de tudo o que está acima.

Ligar o agente a sistemas reais é um projeto de identidade, política e revisão. É esse o recorte da adoção do Kiro na RFX: servidores MCP com permissão mínima, agentes por função, registry aprovado para o time e a convenção versionada no repositório.

Perguntas frequentes

O que é MCP no Kiro?

MCP (Model Context Protocol) é o padrão aberto que liga aplicações de IA a sistemas externos. No Kiro, cada servidor MCP configurado no arquivo mcp.json do workspace ou do usuário, ou dentro de um agente personalizado, entrega ferramentas novas ao agente: consultar uma conta AWS, ler documentação interna, abrir um chamado. Por isso cada servidor entra com a menor permissão que resolve a tarefa.

Qual a diferença entre Powers e servidores MCP no Kiro?

Um servidor MCP configurado direto expõe todas as ferramentas ao agente desde o início. Um Power empacota instruções (skills), servidores MCP opcionais e palavras-chave de ativação em um plugin.json; o Kiro carrega o contexto e as ferramentas do Power só quando a conversa menciona essas palavras, o que reduz o contexto de base. Powers é um recurso do produto e não tem relação com o plano de assinatura chamado Power.

Dá para impedir que o time instale servidores MCP sem aprovação?

Para usuários enterprise do Kiro, sim: o administrador desliga o MCP no console do Kiro ou publica um registry com a lista de servidores aprovados. O Kiro sincroniza a lista na inicialização e a cada 24 horas e encerra servidor fora dela. A própria documentação avisa que a aplicação é feita no cliente, contornável por quem administra a máquina, e não vale para login com Builder ID ou login social.

ViewOnlyAccess ou ReadOnlyAccess para o Kiro consultar a conta AWS?

ViewOnlyAccess enxerga recursos e metadados, mas não lê conteúdo de objeto no Amazon S3, eventos de log nem dados do Cost Explorer. ReadOnlyAccess lê conteúdo: objetos do S3, itens do DynamoDB, eventos de log e mensagens do SQS. Para um agente, o ponto de partida mais seguro é ViewOnlyAccess com uma política adicional só com as leituras que a tarefa exige.

Posso usar autoApprove nas ferramentas MCP?

Pode, para ferramentas de leitura, de origem confiável e de escopo limitado, como recomenda a documentação do Kiro. Nunca use autoApprove com asterisco em servidor que escreve. Em workspace não confiável, o Kiro pede aprovação em toda chamada MCP, inclusive das ferramentas listadas em autoApprove.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções, IA e Cloud | RFX Tecnologia

Arquiteto de Soluções, IA e Cloud na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.