As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Configuração de recursos para exemplos
<a name="example-policies-reference"></a>

Os exemplos nesta seção foram escritos em um gateway ilustrativo em vez de em um gateway que você já tem. Não há nada aqui na sua conta. `InsuranceAPI`,`ClaimsAgent`, e os três alvos de `Claims*` inferência são nomes inventados para um aplicativo de sinistros de seguros, escolhidos para que cada exemplo possa compartilhar um conjunto de ferramentas, tipos de parâmetros e princípios. Substitua seu próprio ARN de gateway, nomes de destino e nomes de ferramentas ao adaptar um exemplo.

Cada exemplo autoriza solicitações para esse gateway:

```
arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5
```

Substitua esse ARN pelo ARN do seu próprio gateway ao adaptar um exemplo. O gateway pertence a um aplicativo de sinistros de seguros e tem cinco alvos cobrindo cada tipo de alvo que a Policy in AgentCore autoriza: um alvo do Model Context Protocol (MCP), um alvo de AgentCore tempo de execução e três alvos de inferência.

Esta página descreve os nomes das ações, os esquemas de ferramentas, os corpos da solicitação e os princípios aos quais os exemplos se referem. Leia uma vez e os demais exemplos não precisarão de configuração adicional.

## Nomes das ações
<a name="example-policies-reference-actions"></a>

O nome da ação que você escreve em uma política depende do tipo de destino que atende à solicitação. Para tudo, exceto o MCP, isso também depende do método e do caminho que o chamador usou.


| Destino | Tipo | Action name (Nome da ação) | 
| --- | --- | --- | 
|  `InsuranceAPI`  | MCP |  `AgentCore::Action::"InsuranceAPI___file_claim"`(uma ação por ferramenta) | 
|  `ClaimsAgent`  | AgentCore Tempo de execução |  `AgentCore::Action::"ClaimsAgent___POST:/invocations"`  | 
|  `ClaimsChat`  | Inferência |  `AgentCore::Action::"ClaimsChat___POST:/v1/chat/completions"`  | 
|  `ClaimsResponses`  | Inferência |  `AgentCore::Action::"ClaimsResponses___POST:/v1/responses"`  | 
|  `ClaimsMessages`  | Inferência |  `AgentCore::Action::"ClaimsMessages___POST:/v1/messages"`  | 

Uma meta de MCP produz uma ação por ferramenta, portanto, uma política pode nomear uma única ferramenta. Todos os outros tipos de alvo produzem uma ação por combinação de método e caminho, portanto, uma política nomeia o destino e o caminho em vez de um recurso individual.

### Alvos de inferência e caminhos de API
<a name="example-policies-reference-inference-paths"></a>

Um destino de inferência é configurado para um formato de API, portanto, um gateway que oferece mais de uma API de inferência tem um alvo por API. É por isso que o gateway de referência tem três. Cada uma carrega um corpo de solicitação diferente, portanto, uma política escrita para uma não é transferida para outra.


| Destino | Caminho da API | Envelope | 
| --- | --- | --- | 
|  `ClaimsChat`  |  `POST /v1/chat/completions`  | Conclusões do OpenAI Chat | 
|  `ClaimsResponses`  |  `POST /v1/responses`  | Respostas OpenAI | 
|  `ClaimsMessages`  |  `POST /v1/messages`  | Mensagens antrópicas | 

Um gateway também pode expor`GET /v1/models`, o que lista os modelos disponíveis. Ela não possui corpo de solicitação, portanto, uma política `ClaimsChat___GET:/v1/models` pode corresponder apenas ao principal, à ação e ao recurso.

**Importante**  
Para governar completamente a inferência, escreva uma política para cada ação de inferência no gateway. Uma nomenclatura de política só `ClaimsChat___POST:/v1/chat/completions` deixa os `/v1/messages` destinos `/v1/responses` e os alvos sem endereçamento e, como os três envelopes colocam o prompt em lugares diferentes, uma condição escrita para um não pode ser reutilizada literalmente para outro. Para obter mais informações, consulte [Inferência de corpos de solicitação por caminho](#example-policies-reference-inference-bodies).

Para ver as regras completas, incluindo destinos de proxy HTTP, consulte [Nomes de ações por tipo de destino](policy-scope.md#policy-guardrails-action-naming).

## Ferramentas MCP no alvo da InsuranceAPI
<a name="example-policies-reference-tools"></a>

O `InsuranceAPI` alvo expõe oito ferramentas. O tipo Cedar de cada parâmetro vem do tipo de esquema JSON. Esse tipo determina quais operadores você pode usar no parâmetro em uma condição. Para obter mais informações, consulte [Tipos de parâmetros em condições](#example-policies-types).

API de seguro\_\_\_get\_contract  
Recupere detalhes do contrato de seguro, como cobertura e datas de vigência.  
 **Parâmetros:**   
+  `contractId`(string, required) - O identificador do contrato de seguro

API de seguro \_\_\_file\_claim  
Registre uma reclamação de seguro.  
 **Parâmetros:**   
+  `contractId`(string, required) - O identificador do contrato de seguro
+  `claimType`(string, obrigatório) - Tipo de reclamação:`health`,`property`, ou `auto` 
+  `amount`(número, obrigatório) - Valor da reclamação
+  `policyTermMonths`(inteiro, obrigatório) - Duração do prazo da apólice, em meses
+  `description`(string, opcional) - Descrição da reivindicação

API de seguros \_\_\_Atualizar\_Cobertura  
Atualize a cobertura da apólice.  
 **Parâmetros:**   
+  `contractId`(string, required) - O identificador do contrato de seguro
+  `coverageType`(string, obrigatório) - Tipo de cobertura, como `liability` ou `collision` 
+  `newLimit`(número, obrigatório) - Novo limite de cobertura

API de seguros \_\_\_get\_claim\_status  
Verifique o status da reclamação.  
 **Parâmetros:**   
+  `claimId`(string, obrigatório) - O identificador da solicitação

   **Retorna:** `claimId` (string), `status` (string)

API de seguro\_\_\_Calculate\_Premium  
Calcule um prêmio de seguro.  
 **Parâmetros:**   
+  `coverageType`(string, obrigatório) - Tipo de cobertura
+  `coverageAmount`(número, obrigatório) - Valor da cobertura
+  `riskFactors`(objeto, opcional) - Fatores de avaliação de risco, com um membro `region` (string) e um membro `priorClaims` (inteiro)

API de seguro\_\_\_aprovar\_reclamação  
Aprovar uma reclamação apresentada. Exemplos temporais usam essa ferramenta como a aprovação que deve preceder um desembolso.  
 **Parâmetros:**   
+  `claimId`(string, obrigatório) - O identificador da solicitação
+  `approved`(booleano, obrigatório) - Se a solicitação foi aprovada
+  `approvedAmountCents`(inteiro, obrigatório) - Valor aprovado, em centavos

   **Retorna:** `claimId` (string), `approved` (booleano), `approvedAmountCents` (inteiro)

API de seguro\_\_\_desembolso\_pagamento  
Desembolse o pagamento de uma reclamação aprovada.  
 **Parâmetros:**   
+  `claimId`(string, obrigatório) - O identificador da solicitação
+  `amountCents`(inteiro, obrigatório) - Valor a ser desembolsado, em centavos

   **Retorna:** `claimId` (string), `status` (string), `amountCents` (inteiro)

API de seguro \_\_\_Excluir\_reclamação  
Exclua permanentemente um registro de reclamação. Os exemplos usam essa ferramenta como uma operação delicada que a maioria dos diretores não deve realizar.  
 **Parâmetros:**   
+  `claimId`(string, obrigatório) - O identificador da solicitação

## Corpo da solicitação no destino do tempo de execução
<a name="example-policies-reference-bodies"></a>

Um destino de tempo de execução é autorizado como uma ação e `context.input` contém o corpo da solicitação em vez de um conjunto de argumentos declarados da ferramenta.

 `ClaimsAgent___POST:/invocations`   
Um alvo AgentCore do Runtime hospedando um assistente de sinistros.  
 **Corpo da solicitação:**   
+  `prompt`(string) - A mensagem do usuário para o agente
+  `sessionAttributes`(objeto, opcional) - Caller-supplied atributos

   **Corpo da resposta:** `completion` (string)

**Importante**  
Para um destino de tempo de execução, os campos que uma política pode ler vêm do **esquema OpenAPI declarado no destino do gateway**, não do que o tempo de execução realmente envia. Um campo que o esquema não declara não é endereçável — `context.output.<field>` funciona somente para uma propriedade de resposta que o esquema lista, e o mesmo se aplica a `output.<field>` um predicado temporal.  
Se uma condição em um campo de tempo de execução for rejeitada como não declarada, verifique o esquema do destino em vez do código do tempo de execução.

## Corpos de solicitação de inferência por caminho
<a name="example-policies-reference-inference-bodies"></a>

Para um destino de inferência, `context.input` contém o corpo da solicitação da API que o chamador invocou. Os três envelopes colocam o texto da conversa em estruturas diferentes, o que é a coisa mais importante a saber antes de escrever uma condição ou um caminho de dados de proteção contra um alvo de inferência.

 `ClaimsChat___POST:/v1/chat/completions`   
Conclusões do OpenAI Chat. A conversa é uma matriz de objetos de mensagem; um prompt do sistema é uma mensagem com`role: system`.  

```
{
  "model": "openai.gpt-oss-120b-1:0",
  "messages": [
    { "role": "system", "content": "You are a claims assistant." },
    { "role": "user",   "content": "What is the status of claim C-1001?" }
  ]
}
```
 **Corpo da resposta:** `choices` (matriz), cada entrada com um `message` objeto segurando `role` e `content` 

 `ClaimsResponses___POST:/v1/responses`   
Respostas OpenAI. O prompt é um único `input` membro, que pode ser uma string simples **ou** uma lista de itens, cada um contendo uma `content` matriz. O prompt do sistema é um `instructions` membro separado.  

```
{
  "model": "openai.gpt-oss-120b-1:0",
  "instructions": "You are a claims assistant.",
  "input": "What is the status of claim C-1001?"
}
```
 **Corpo da resposta:** `output` (matriz), cada entrada com uma `content` matriz de blocos contendo `text` 

 `ClaimsMessages___POST:/v1/messages`   
Mensagens antrópicas. A conversa é uma `messages` matriz que `content` pode ser uma string ou uma matriz de blocos digitados. O prompt do sistema é um `system` membro de nível superior, não uma mensagem.  

```
{
  "model": "anthropic.claude-sonnet-4-5-20250929-v1:0",
  "max_tokens": 1024,
  "system": "You are a claims assistant.",
  "messages": [
    { "role": "user", "content": "What is the status of claim C-1001?" }
  ]
}
```
 **Corpo da resposta:** `content` (matriz) de blocos contendo `text` 

### Localizações de texto para cada caminho
<a name="example-policies-reference-inference-fields"></a>

A tabela a seguir fornece a localização do texto da conversa em cada caminho, para ambas as direções. Use-o sempre que precisar apontar uma grade de proteção para o que um chamador ou modelo realmente disse.


| Caminho da API | Texto de entrada | Texto de saída | 
| --- | --- | --- | 
|  `/v1/chat/completions`  |  `messages[*].content`  |  `choices[*].message.content`  | 
|  `/v1/responses`  |  `input`, `input[*].content[*].text`, `instructions`  |  `output[*].content[*].text`  | 
|  `/v1/messages`  |  `messages[*].content`, `messages[*].content[*].text`, `system`  |  `content[*].text`  | 

Dois caminhos listam mais de um local de entrada porque o formato da conexão varia. Ativado`/v1/responses`, `input` é uma sequência de caracteres simples ou uma lista de itens, então o texto está `input` em um caso e `input[*].content[*].text` em outro. `/v1/messages`Ativado, a mensagem `content` é uma string ou uma matriz de blocos digitados. Nomear as duas formas abrange qualquer forma de fio, sem que você precise saber qual foi o chamador enviou.

**Importante**  
Esses locais estão dentro de matrizes e registros, então você **não pode** alcançá-los com um `context.input.<field>` caminho vazio — `context.input.messages` é um`Set<record>`, não é texto, e o Dogwood não tem operador de projeção de matriz, então `messages[*].content` há um erro de análise em um caminho de campo. Em vez disso, os caminhos de dados do Guardrail os alcançam com uma string JSONPath com `$` prefixo -. Para obter mais informações, consulte Como [alcançar texto dentro de matrizes com um JSONPath](example-policies-guardrails.md#example-policies-guardrails-jsonpath).  
Para uma condição comum de cedro, somente membros escalares são utilizáveis — `context.input.model` é a `String` e funciona, embora `context.input.messages` não possa ser comparada ou correspondida ao padrão.

## Entidades principais
<a name="example-policies-reference-principals"></a>

O tipo de entidade principal depende de como o gateway autentica os chamadores de entrada. Os exemplos usam qualquer tipo que o padrão exija, e a maioria dos padrões funciona com qualquer um deles.

AgentCore::OAuthUser  
O gateway usa um autorizador JWT. O ID da entidade é a `sub` declaração do token, e as outras reivindicações do token estão disponíveis como tags por meio de `principal.hasTag("<claim>")` `principal.getTag("<claim>")` e. Os exemplos usam três afirmações: `username``role`, `scope` e.

AgentCore::IamEntity  
O gateway usa`AWS_IAM`. O ID da entidade é o ARN do chamador com qualquer nome de sessão removido, portanto, uma função assumida aparece como. `arn:aws:sts::<account>:assumed-role/<role-name>` Esse formulário é estável em todas as sessões, então você pode combiná-lo com `principal ==` ou combinar uma família de funções`principal.id like`.

Para ver a lista completa dos principais atributos e como as declarações são mapeadas para tags, consulte [Principal](policy-scope.md#policy-principal).

## Tipos de parâmetros em condições
<a name="example-policies-types"></a>

O tipo de esquema JSON de um parâmetro de ferramenta determina seu tipo Cedar, e o tipo Cedar determina quais operadores são válidos nele. Fazer isso de forma errada produz uma política que falha na validação ou nega todas as solicitações em tempo de execução. Portanto, verifique o tipo do parâmetro antes de escrever uma condição nele.


| Tipo de esquema JSON | Tipo de cedro | Como compará-lo | 
| --- | --- | --- | 
|  `string`  |  `String`  |  `==`,`!=`,`like`, e defina a associação com `.contains()`  | 
|  `integer`  |  `Long`  |  `==`,`<`,`⇐`,`>`, `>=` com um literal inteiro | 
|  `number`  |  `decimal`  | Somente`.lessThan()`,`.lessThanOrEqual()`,, `.greaterThan()``.greaterThanOrEqual()`, e`==`, cada um contra um `decimal("…​")` literal. Cedar não tem `>` operador `<` ou nem literal `decimal` de ponto flutuante. | 
|  `boolean`  |  `Bool`  |  `==`, e uso direto em uma condição | 
|  `object`  |  `Record`  | Acesse membros com`.`, e teste para um membro com `has`  | 
|  `array`  |  `Set`  |  `.contains()`, `.containsAll()`, `.containsAny()`  | 
|  `null`  |  `Entity`  | Não é comparável. Um `null` argumento é omitido`context.input`, então teste sua ausência com `!(context.input has <field>)`  | 

Esses são os nomes de tipo do próprio Cedar e são os nomes que o esquema gerado usa. Para ver o mapeamento completo, incluindo as notas sobre cada conversão, consulte [Contexto](policy-schema-constraints.md#policy-context).

### Parâmetros numéricos
<a name="example-policies-numeric"></a>

Os números são onde é mais provável que uma condição seja escrita de uma forma que o serviço rejeite. Confirme o tipo do parâmetro e os operadores que esse tipo suporta antes de escrever a comparação.

 **E `integer` se torna um cedro`Long`.** Compare-o com os operadores comuns e com um literal inteiro:

```
context.input.policyTermMonths >= 12
```

 **A `number` se torna um cedro`decimal`.** O Cedar não define nenhum `>=` operador `<``⇐`,`>`, ou para `decimal` e não tem literal de ponto flutuante, então use os métodos de comparação e um literal entre aspas`decimal("…​")`:

```
context.input.amount.greaterThan(decimal("1000.00"))
```

Ambos `context.input.amount > 1000.00` `context.input.amount < 1000` são inválidos. O primeiro não tem operador para o tipo; o segundo compara `decimal` a com a. `Long`

 **Dentro de um `temporal { }` bloco, o pedido requer um`integer`.** A `decimal` é rejeitado em uma comparação de pedidos, assim como a. `string` A soma tem o mesmo requisito: `sum` precisa de um `integer` sumário. A igualdade (`==`,`!=`) é irrestrita, desde que ambos os lados sejam do mesmo tipo. Para obter mais informações, consulte [Exemplos de políticas temporais](example-policies-temporal.md).

O serviço relata um erro de tipo de qualquer um desses tipos quando você cria a política. A mensagem nomeia o tipo esperado e real com um ponteiro de linha e coluna, como`unexpected type: expected Long but saw decimal`, ou `comparison requires numeric operands on both sides` dentro de um `temporal` bloco.

**dica**  
Modele qualquer valor que uma política temporal tenha como total ou limite como `integer` no esquema de sua ferramenta. É por isso que o gateway de referência indica o dinheiro de duas maneiras. `file_claim`assume `amount` como`number`, porque suas regras são comparações pontuais. `approve_claim`recebe um inteiro `approvedAmountCents` e `disburse_payment` recebe um inteiro`amountCents`, porque os exemplos temporais os agregam. Vale a pena adotar representar dinheiro como unidades inteiras menores para qualquer ferramenta cujos valores uma política temporal precise totalizar.

[Para o limite de precisão decimal e outras restrições do esquema, consulte Restrições e cotas.](policy-schema-constraints.md)

Os parâmetros opcionais estão ausentes `context.input` quando o chamador os omite, então teste um membro `has` antes de lê-lo:

```
context.input has description && context.input.description != ""
```

O guarda é obrigatório em vez de consultivo. A leitura de um atributo opcional sem ele falha na criação da política com`unable to guarantee safety of access to optional attribute`, e a falha é assíncrona — um 202 seguido por. `CREATE_FAILED` Um parâmetro que o esquema marca como obrigatório não precisa de proteção.

As incompatibilidades de tipo falham da mesma forma. `.contains(1)`em uma matriz de relatórios de cadeias de caracteres`the types Long and String are not compatible`, com um ponteiro de linha e coluna.