# Melhores práticas de segurança para AgentCore Runtime
Este tópico consolida as melhores práticas de segurança para o Amazon Bedrock AgentCore Runtime. Use essas recomendações para proteger suas implantações de agentes, proteger dados e seguir o princípio do menor privilégio.
**Topics**
+ [Isolamento de sessão e proteção de dados](#security-bp-session-isolation)
+ [IAM e privilégio mínimo](#security-bp-iam-least-privilege)
+ [Resource-based políticas e acesso entre contas](#security-bp-resource-policies)
+ [Prevenção contra representante confuso](#security-bp-confused-deputy)
+ [Controle seu tempo de execução com um AgentCore Gateway](#security-bp-front-with-gateway)
+ [Práticas recomendadas de autenticação](#security-bp-authentication)
+ [Gerenciamento de credenciais e segredos](#security-bp-credentials)
+ [Segurança de rede](#security-bp-network)
+ [Criptografia](#security-bp-encryption)
+ [Auditoria e monitoramento](#security-bp-auditing)
+ [Modelo de responsabilidade compartilhada](#security-bp-shared-responsibility)
+ [Segurança de execução de comandos](#security-bp-command-execution)
+ [Servidor da plataforma VM](#security-bp-platform-server)
## Isolamento de sessão e proteção de dados
O Amazon Bedrock AgentCore Runtime fornece fortes limites de isolamento por meio de microVMS dedicadas. Siga estas práticas para manter a proteção de dados:
+ **Entenda o limite de isolamento** — Cada sessão de usuário é executada em uma microVM dedicada com CPU, memória e sistema de arquivos isolados. Os comandos e o código do agente não podem acessar as cargas de trabalho de outros clientes nem escapar dos limites da VM. Após a conclusão da sessão, toda a microVM é encerrada e a memória é higienizada.
+ **Imponha mapeamentos de sessão para usuário em seu back-end — não impõe mapeamentos de** sessão para usuário. AgentCore O back-end do cliente deve manter o relacionamento entre os usuários e seus IDs de sessão e implementar o gerenciamento do ciclo de vida, como o número máximo de sessões por usuário.
+ **Esteja ciente do comportamento de permissão do sistema de arquivos** — Ao usar [sistemas de arquivos persistentes](runtime-filesystem-configurations.md), as permissões são armazenadas, mas não aplicadas na sessão. `chmod`e `stat` funcionam corretamente, mas as verificações de acesso sempre são bem-sucedidas porque o agente é executado como o único usuário na microVM.
+ **Entenda a exposição de credenciais na VM** — Qualquer código ou ator executado dentro da microVM pode acessar as credenciais da função de execução chamando o endpoint de metadados (MMDS). Defina cuidadosamente suas permissões de função de execução. Para obter mais informações, consulte [Gerenciamento de credenciais.](security-credentials-management.md)
## IAM e privilégio mínimo
Aplique o princípio do menor privilégio a todas as políticas do IAM associadas aos seus recursos do AgentCore Runtime:
+ **Não use CLI-generated políticas na produção** — As políticas do IAM criadas pela AgentCore CLI são projetadas para fins de desenvolvimento e teste. Essas permissões concedem amplo acesso e não são adequadas para produção. Crie políticas personalizadas do IAM que restringem as permissões somente aos recursos e ações específicos necessários. Para ver a referência completa, consulte [Permissões do IAM para AgentCore tempo de execução](runtime-permissions.md).
+ **Permissões de escopo para ARNs de tempo de execução específicos** — Evite declarações de recursos curingas. Use o ARN completo dos seus recursos de tempo de execução nos campos de política `Resource` do IAM.
+ **Restringir `InvokeAgentRuntimeForUser`** — Somente diretores confiáveis devem ter essa permissão. Defina o escopo para recursos de tempo de execução específicos usando condições de recursos do IAM.
+ **Negar delegação de ID de usuário quando não for necessária** — Para tempos de execução em que a delegação de ID de usuário não é necessária, negue explicitamente a ação:
```
{
"Statement": [
{
"Sid": "DenyUserIdDelegation",
"Effect": "Deny",
"Action": "bedrock-agentcore:InvokeAgentRuntimeForUser",
"Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT_ID:runtime/*"
}
]
}
```
+ **Evite o aumento de privilégios** — garanta que a função de execução associada ao seu tempo de execução tenha privilégios iguais ou menores do que os principais que podem invocá-la. Para obter mais informações, consulte [Gerenciamento de credenciais.](security-credentials-management.md)
+ **Use chaves de condição do IAM para impor implantações de VPC** — `bedrock-agentcore:subnets` Use chaves de condição para exigir que todos `bedrock-agentcore:securityGroups` os tempos de execução sejam implantados em VPCs aprovadas. Para ver exemplos, consulte [Usar chaves de condição de VPC com AgentCore ](security-vpc-condition.md) Runtime.
+ **Use o IAM Access Analyzer** — valide suas políticas do IAM para garantir que elas sigam as melhores práticas e os princípios de privilégios mínimos.
## Resource-based políticas e acesso entre contas
Resource-based as políticas fornecem controle de acesso refinado diretamente em seus recursos de tempo de execução:
+ **Entenda a autorização hierárquica** — Para operações de API de tempo de execução`InvokeAgentRuntime`, como`InvokeAgentRuntimeCommand`, e`InvokeAgentRuntimeCommandShell`, AWS avalia políticas tanto no tempo de execução do agente quanto no endpoint do agente. Ambos devem permitir a ação.
+ **Configure os dois recursos para acesso entre contas** — Para conceder acesso entre contas, crie políticas baseadas em recursos no tempo de execução do agente e no endpoint do agente. Se um dos recursos não tiver uma permissão explícita, a solicitação será negada.
+ **Lembre-se de que a negação explícita sempre vence** — se alguma política (baseada em identidade ou em recursos) negar explicitamente uma ação, o acesso será negado independentemente de outras políticas.
Para obter detalhes completos, consulte [Resource-based as políticas do Amazon Bedrock AgentCore](resource-based-policies.md).
## Prevenção contra representante confuso
Proteja suas funções de execução do confuso problema substituto usando chaves de contexto de condição global em políticas de confiança:
+ **Use `aws:SourceArn` e `aws:SourceAccount`** — Adicione essas condições à sua política de confiança da função de execução para limitar quais AgentCore recursos podem assumir a função:
```
{
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "bedrock-agentcore.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:*"
}
}
}
]
}
```
+ **Use o ARN completo quando possível** — Se você conhece o recurso de tempo de execução específico, use o ARN completo em `aws:SourceArn` vez de curingas.
Para obter mais informações, consulte [Cross-service Confused Deputy Prevention](cross-service-confused-deputy-prevention.md).
## Controle seu tempo de execução com um AgentCore Gateway
Um padrão comum é equipar seu AgentCore Runtime com um AgentCore Gateway para que o gateway se torne o único ponto de entrada controlado para o tempo de execução. Colocar um gateway na frente permite aplicar controles **fora** do próprio ambiente do agente:
+ **Policy-based autorização** — Use o mecanismo de política do gateway para controlar quais chamadores podem invocar quais alvos e sob quais condições. Para obter mais informações, consulte [Usar políticas para controlar o acesso aos destinos do gateway](policy.md).
+ **Guardrails — Aplique** o Amazon Bedrock Guardrails por meio do mecanismo de políticas para filtrar solicitações e respostas. Para obter mais informações, consulte [Usar grades de proteção nas](policy-guardrails-in-policies.md) políticas.
+ **Interceptores de solicitação e resposta** — Inspecione ou transforme o tráfego com as funções Lambda do interceptor configuradas no gateway.
Esses controles protegem você somente se todo o tráfego realmente fluir pelo gateway. Se um chamador puder acessar o tempo de execução diretamente, ele ignorará totalmente as políticas, as grades de proteção e os interceptores do gateway. Para evitar isso, restrinja o tempo de execução para aceitar invocações somente quando elas se originarem do seu gateway. A forma como você faz isso depende do tipo de autorização de entrada do tempo de execução:
+ **Tempos de execução do IAM (SigV4)** — anexe uma política baseada em recursos que restrinja a invocação à função de execução do gateway. Consulte [Restringir a invocação de entrada do IAM (SigV4)](runtime-oauth.md#runtime-restrict-iam-gateway) ao seu gateway.
+ Tempos de execução do **OAuth (JWT) — Configure `allowedWorkloadConfiguration` no autorizador do tempo de execução**. Consulte [Restringir a invocação ao seu gateway](runtime-oauth.md#deploy-agent-allowed-workload).
Para configurar isso, você [cria o gateway](gateway-create.md), [implanta seu tempo de execução](runtime-oauth.md#deploy-agent) e, em seguida, [adiciona o tempo de execução como um destino](gateway-target-http-runtime.md) de gateway nesse gateway. [Para a configuração do destino, a autorização de saída e o formato do URL de invocação, consulte AgentCore Destinos de tempo de execução.](gateway-target-http-runtime.md)
## Práticas recomendadas de autenticação
AgentCore O Runtime é compatível com a autenticação de token do portador IAM SigV4 e JWT. Siga estas práticas para proteger o acesso:
+ **Escolha o método de autenticação certo** — use o IAM SigV4 para chamadas de serviço a serviço dentro. AWS Use a autenticação de token portador do JWT quando os usuários finais se autenticarem diretamente por meio de um provedor de identidade. Um tempo de execução pode oferecer suporte a um método por vez; crie versões separadas para diferentes tipos de autenticação.
+ **Prefira a identificação JWT-based do usuário para produção** — Quando seu agente recupera tokens OAuth em nome dos usuários finais, prefira o caminho do token portador do JWT (`GetWorkloadAccessTokenForJWT`), que valida o emissor, a assinatura e a expiração do token. O UserId caminho (`GetWorkloadAccessTokenForUserId`/`X-Amzn-Bedrock-AgentCore-Runtime-User-Id`header) trata o identificador do usuário como uma string opaca sem verificação de IdP — use-o somente para desenvolvimento, cenários de início rápido ou arquiteturas corporativas que resolvam a identidade do usuário no upstream. Para obter mais informações, consulte [Obter token de acesso à carga](get-workload-access-token.md) de trabalho.
+ **Configure completamente os autorizadores do JWT** — Ao usar a autenticação do JWT, configure todos os campos de validação disponíveis: URL de descoberta, públicos permitidos, clientes permitidos, escopos permitidos e declarações personalizadas necessárias.
+ **Nunca codifique tokens no código de produção** — use mecanismos seguros de recuperação de tokens. Tokens codificados são um risco de segurança no controle de origem e nos artefatos implantados.
+ **Derive o ID de usuário do principal autenticado** — Se você usar o `X-Amzn-Bedrock-AgentCore-Runtime-User-Id` cabeçalho, o valor deverá ser derivado do contexto do principal autenticado (identidade do chamador do IAM ou declarações de token do usuário), não de valores arbitrários fornecidos pelo cliente. Isso impede que usuários autenticados se passem por outros usuários.
+ **Negue ForUserId onde não for necessário** — Para cargas de trabalho que sempre têm um JWT disponível, negue explicitamente `bedrock-agentcore:GetWorkloadAccessTokenForUserId` e `bedrock-agentcore:InvokeAgentRuntimeForUser` nas políticas do IAM. Isso garante que toda a identificação do usuário passe pelo caminho JWT verificado criptograficamente.
+ **Configure políticas de endpoint de VPC para seu método de autenticação — as políticas** de endpoint de VPC só podem restringir os chamadores com base nos diretores do IAM, não nos usuários do OAuth. Para OAuth-based solicitações, `Principal` defina como `*` na política de endpoint. Para SigV4-based autenticação, especifique as identidades do IAM permitidas.
Para obter detalhes sobre a implementação, consulte [Autenticar e autorizar com Autenticação de Entrada e Autenticação de Saída.](runtime-oauth.md)
## Gerenciamento de credenciais e segredos
Proteja as credenciais usadas por seus agentes e ambientes de execução:
+ **Use o AgentCore Identity para autenticação de saída** — O AgentCore Identity gerencia as credenciais do OAuth e as chaves de API com segurança, evitando a exposição de credenciais no código ou nos registros do agente. Use-o para acesso a todos os serviços de terceiros (Slack GitHub, Zoom).
+ **Entenda a exposição das credenciais do MMDS** — O MicroVM Metadata Service (MMDS) fornece credenciais de função de execução para qualquer código executado na VM, semelhante ao IMDS do EC2. Defina as permissões da função de execução somente para o que seu agente exige.
+ **Habilitar o MMDSv2** — A partir de 30 de junho de 2026, os tempos de execução do seu agente devem ter o MMDSv2 ativado. Os tempos de execução sem o MMDSv2 habilitado não podem ser invocados e retornar um. `ValidationException` Para habilitar, ligue `UpdateAgentRuntime` com `requireMMDSV2` definido como `true` in`metadataConfiguration`. Para obter mais informações sobre como resolver esse erro, consulte Solução de problemas do [ ValidationException MMDSv2](runtime-troubleshooting.md#troubleshoot-runtime-mmdsv2-validation).
+ **Execute contêineres como usuários não root** — Ao criar imagens de contêiner personalizadas, configure-as para serem executadas como um usuário não root. Isso limita o impacto de possíveis vulnerabilidades de execução de código.
+ **Credenciais autônomas e delegadas pelo usuário separadas** — Use a autenticação delegada pelo usuário (Concessão de Código de Autorização) quando seu agente agir em nome de um usuário específico. Use a autenticação autônoma (concessão de credenciais do cliente) quando o agente opera de forma independente.
Para obter mais informações, consulte [Gerenciamento e [AgentCore identidade](identity.md) de credenciais](security-credentials-management.md).
## Segurança de rede
Acesso seguro à rede de e para seus ambientes AgentCore Runtime:
+ **Implante tempos de execução em uma VPC para acesso privado a recursos** — configure a conectividade da VPC para acessar bancos de dados privados, APIs internas e serviços sem expô-los à Internet. Para obter detalhes de configuração, consulte [Configurar o AgentCore Runtime para VPC](agentcore-vpc.md).
+ **Use AWS PrivateLink para acesso à API** — Crie endpoints VPC de interface para o plano de AgentCore dados (`com.amazonaws.region.bedrock-agentcore`) e o plano de controle (`com.amazonaws.region.bedrock-agentcore-control`) para evitar a passagem pela Internet. Para obter mais informações, consulte [Usar AWS PrivateLink](vpc-interface-endpoints.md).
+ **Aplique o mínimo de privilégios aos grupos de segurança** — defina regras de saída que permitam somente o tráfego mínimo necessário. Não abra um amplo acesso externo, a menos que seja necessário.
+ **Configure os endpoints de VPC necessários para agentes de contêiner — Para agentes** de VPC-mode contêiner, configure os endpoints de VPC para ECR (`com.amazonaws.region.ecr.dkr`,`com.amazonaws.region.ecr.api`), S3 (endpoint de `com.amazonaws.region.s3` gateway) e Logs (). CloudWatch `com.amazonaws.region.logs` O endpoint do gateway S3 elimina as cobranças de processamento de dados do gateway NAT para extrair camadas de imagem ECR.
+ **Defina o escopo da política de endpoint do gateway S3 para agentes de contêineres** — Restrinja a política de endpoint do gateway S3 somente ao bucket que o Amazon ECR usa para armazenamento na camada de imagem:
```
{
"Statement": [
{
"Sid": "AllowECRLayerAccess",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::prod-region-starport-layer-bucket/*"]
}
]
}
```
`region`Substitua pelo identificador AWS da sua região (por exemplo,`us-east-2`).
+ **Defina o escopo da política de endpoint do gateway S3 para agentes de implantação direta de código — Para implantações** baseadas em zip, restrinja a política ao bucket interno de artefatos de código de propriedade do serviço. Adicione uma `aws:PrincipalServiceName` condição para garantir que somente o responsável pelo AgentCore serviço possa acessar os buckets por meio dessa política de endpoint:
```
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::acr-code-*-region-an",
"arn:aws:s3:::acr-code-*-region-an/*"
],
"Condition": {
"StringEquals": {
"aws:PrincipalServiceName": "bedrock-agentcore.amazonaws.com"
}
}
}
]
}
```
`region`Substitua pelo identificador AWS da sua região (por exemplo,`us-west-2`). Os buckets AgentCore de artefatos de código são criados nos buckets de uso geral do [namespace regional Account](https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html#account-regional-gp-buckets). Só AWS pode possuir os nomes reais dos buckets usados pelo serviço. A `aws:PrincipalServiceName` condição garante que somente o responsável pelo AgentCore serviço possa acessar buckets por meio dessa política de endpoint. Se você também usa [sistemas de arquivos persistentes](runtime-filesystem-configurations.md), adicione o bucket de armazenamento da sessão a essa política. Para obter mais informações, consulte [Configurar o AgentCore tempo de execução para VPC](agentcore-vpc.md).
+ **Use sub-redes privadas com gateways NAT** — As sub-redes públicas não fornecem acesso à Internet para o Runtime. AgentCore Sempre coloque ENIs de tempo de execução em sub-redes privadas com uma rota para um gateway NAT para acesso de saída à Internet.
+ **Segurança de transporte** — Todas as conexões usam TLS 1.2 ou superior. WebSocket conexões, inclusive`InvokeAgentRuntimeCommandShell`, usam WSS (WebSocket Secure) exclusivamente por HTTPS. `ws://`Conexões de texto sem formatação não são suportadas.
+ **Imponha limites de cabeçalho** — cabeçalhos personalizados são limitados a 4 KB por valor e 20 cabeçalhos por tempo de execução. O `Authorization` cabeçalho é reservado para agentes com acesso de entrada OAuth.
## Criptografia
AgentCore O Runtime protege os dados com criptografia em repouso e em trânsito:
+ **Criptografia em trânsito** — Toda a comunicação entre clientes e AgentCore Runtime, e entre AgentCore Runtime e suas dependências, é protegida usando TLS 1.2 ou superior. Isso é configurado por padrão e não requer configuração adicional.
+ **Criptografia em repouso** — Os dados em repouso são criptografados usando chaves de criptografia AWS próprias do AWS Key Management Service (AWS KMS) por padrão.
+ **Use o TLS 1.3 sempre que possível** — Embora o TLS 1.2 seja o mínimo, AWS recomenda o TLS 1.3 para melhorar a segurança e o desempenho.
Para obter mais informações, consulte [Criptografia de dados](data-encryption.md).
## Auditoria e monitoramento
Implemente uma auditoria abrangente para detectar e investigar eventos de segurança:
+ **Habilite o CloudTrail registro** — AWS CloudTrail registra chamadas de API`InvokeAgentRuntime`, incluindo`InvokeAgentRuntimeCommand`,`InvokeAgentRuntimeCommandShell`, e operações do plano de controle. Cada registro inclui identidade do chamador, carimbo de data/hora, endereço IP de origem e status da resposta.
+ **Use CloudWatch registros para auditoria de comandos** — o AgentCore Runtime envia o ID da solicitação e o comando de entrada para o grupo de CloudWatch registros de registros do seu agente. Use esses registros para manter uma trilha de auditoria dos comandos executados em suas sessões.
+ **Correlacione registros usando IDs** de solicitação — Use o ID da solicitação para correlacionar CloudTrail registros (quem chamou a API) com CloudWatch registros (qual comando foi executado).
+ **Configurar filtros métricos e alarmes** — Configure filtros métricos de CloudWatch registros para detectar padrões de comando inesperados ou tentativas de acesso não autorizado. Crie alarmes para notificar sua equipe sobre anomalias.
+ **Registrar relacionamentos de delegação de ID de usuário** — Ao usar o `X-Amzn-Bedrock-AgentCore-Runtime-User-Id` cabeçalho, registre o relacionamento entre o principal autenticado do IAM e o valor do ID de usuário para fins de auditoria.
+ **Habilitar registros de fluxo de VPC** — Para VPC-connected tempos de execução, habilite os registros de fluxo de VPC para auditar o tráfego no nível da rede e identificar padrões de comunicação inesperados.
+ **Analise CloudTrail os registros regularmente** — revise periodicamente os registros em busca de tentativas de acesso não autorizadas, especialmente para cargas de trabalho confidenciais.
## Modelo de responsabilidade compartilhada
Entenda a divisão das responsabilidades de segurança entre você AWS e você:
**AWS responsabilidades:**
+ Infraestrutura segura e isolamento de microVM no nível do hardware
+ Correção do kernel do sistema operacional para todos os modos de implantação
+ Correção de tempo de execução de linguagem para implantações diretas de código
+ Segurança da infraestrutura de rede
+ Disponibilidade e resiliência do serviço
**Suas responsabilidades:**
+ Segurança do código do agente e gerenciamento de dependências
+ Controles de acesso e políticas de recursos do IAM
+ Segurança de comandos executados em sessões de tempo de execução
+ Session-to-user fiscalização do mapeamento
+ Atualizações de imagens de contêineres (para implantações de contêineres) — reconstrua regularmente com a imagem base segura mais recente
+ Validação de entrada e prevenção imediata de injeção — incluindo a validação da `InvokeHarness` entrada ao usar o chicote gerenciado (consulte [Harness compartilha o limite de confiança do AgentCore Runtime](#security-bp-harness-trust-boundary))
+ Configuração de rede (grupos de segurança, VPC endpoints, tabelas de rotas)
**Importante**
Para implantações diretas de código, o AgentCore Runtime aplica automaticamente patches de segurança ao sistema operacional runtime. AgentCore O Runtime não aplica patches de segurança aos tempos de execução da linguagem de programação depois que eles atingem a data de fim do suporte. Os tempos de execução obsoletos são fornecidos no estado em que se encontram e podem conter vulnerabilidades não corrigidas. Para ver os tempos de execução compatíveis, consulte Tempos de [execução compatíveis para implantação de código](runtime-code-deploy-supported-runtimes.md).
**nota**
Os patches de segurança podem expor problemas com o código existente que depende de um comportamento inseguro anterior. Se esse risco não for aceitável, use imagens de contêiner para implantar seu agente.
### Harness compartilha o limite de confiança do AgentCore Runtime
O equipamento gerenciado é baseado no AgentCore Runtime. Ele não adiciona uma camada de segurança entre o chamador e a microVM. O limite de segurança é o mesmo da autenticação AgentCore Runtime: IAM ou JWT combinada com isolamento de microVM.
Para obter o modelo de segurança completo, incluindo detalhes do limite de confiança, riscos dos parâmetros de configuração do modelo e orientação de validação de entrada, consulte o modelo [de responsabilidade compartilhada.](harness-security.md#harness-shared-responsibility)
## Segurança de execução de comandos
AgentCore O Runtime fornece duas APIs de execução de comandos:
+ `InvokeAgentRuntimeCommand`— One-shot, encerrada a execução de comandos não interativos. HTTP/2 Ação do IAM:`bedrock-agentcore:InvokeAgentRuntimeCommand`.
+ `InvokeAgentRuntimeCommandShell`— WebSocket Sessão de shell interativa com acesso PTY persistente. Ação do IAM:`bedrock-agentcore:InvokeAgentRuntimeCommandShell`.
As duas APIs operam dentro do mesmo limite de isolamento da microVM e compartilham o mesmo modelo de segurança. Aplique essas práticas a ambos:
+ **Entenda o limite de segurança** — Os comandos têm acesso total ao sistema de arquivos do contêiner e a todas as credenciais ou segredos configurados na microVM. O limite de isolamento é a própria microVM. No modelo de responsabilidade compartilhada, você é responsável pela segurança de qualquer código executado em seu contêiner de tempo de execução.
+ **Use operações determinísticas para tarefas determinísticas** — Use `InvokeAgentRuntimeCommand` ou `InvokeAgentRuntimeCommandShell` para operações como testes, git e compilações. Não encaminhe operações determinísticas por meio do LLM via. `InvokeAgentRuntime`
+ **Restrinja quem pode executar comandos** — Use as políticas do IAM para limitar quais diretores podem chamar `InvokeAgentRuntimeCommand` ou`InvokeAgentRuntimeCommandShell`. Nem todos os usuários que podem invocar um agente devem ser capazes de executar comandos arbitrários. Exemplo de ARN do recurso:. `arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent`
+ **WebSocket O shell usa somente wss://**— `InvokeAgentRuntimeCommandShell` as conexões são estabelecidas exclusivamente pelo WSS (WebSocket Secure). `ws://`Conexões de texto sem formatação não são suportadas. Os chamadores se autenticam via SigV4 na atualização. WebSocket
+ **Mantenha o tráfego em sua rede** — configure endpoints de VPC para evitar a passagem pela Internet para chamadas de API de execução de comandos.
+ **Defina tempos limite apropriados** — Configure os tempos limite dos comandos com base na duração esperada da execução para evitar o desperdício de recursos em processos descontrolados.
Para obter detalhes completos, consulte [Executar comandos em sessões de tempo de execução](runtime-execute-command.md).
## Servidor da plataforma VM
Cada AgentCore Runtime MicroVM inclui um servidor de plataforma em execução no localhost. Esse servidor gerencia o ciclo de vida da sessão da VM, as operações de armazenamento e fornece acesso ao shell para suportar as operações de tempo de execução. O servidor da plataforma é executado inteiramente dentro da microVM do agente, que é o limite de isolamento — ele não contém nenhum código de infraestrutura essencial para o serviço e não tem acesso às outras sessões ou às cargas de trabalho dos clientes.
**Importante**
Tudo o que é executado na microVM, incluindo as interações com o servidor da plataforma, é de sua responsabilidade sob o modelo de responsabilidade compartilhada. Se o código ou as ferramentas do agente interagirem com o servidor da plataforma, o impacto será limitado à sessão atual da VM — não poderá afetar outras sessões nem ultrapassar os limites do isolamento. No entanto, o acesso não autorizado pode interromper o ciclo de vida da VM da sessão ou fornecer acesso ao shell dentro dessa sessão.
Siga estas práticas para limitar o acesso desnecessário ao servidor da plataforma:
+ **Restrinja o acesso ao localhost no código do agente** — Configure seu agente e todas as ferramentas de rede para impedir o acesso irrestrito ao localhost. O código do agente não deve fazer chamadas HTTP arbitrárias para localhost, a menos que seja necessário para uma integração específica.
+ **Liste as portas necessárias somente para configurações secundárias — Se sua arquitetura usa um padrão container in-container ou sidecar** no localhost, liste explicitamente somente as portas específicas que seus serviços secundários usam. Não abra um amplo acesso ao host local.
+ **Audite as ferramentas de rede para alcançar o host local** — revise todas as ferramentas que você fornece ao seu agente (como ferramentas de solicitação HTTP ou utilitários gerais de rede) para garantir que eles não possam fazer solicitações não intencionais aos endpoints do host local. Aplique a filtragem de URL ou a lista de permissões no nível da ferramenta.