기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 예제에 대한 리소스 구성
<a name="example-policies-reference"></a>

이 섹션의 예제는 이미 있는 게이트웨이가 아닌 하나의 예시 게이트웨이에 대해 작성되었습니다. 여기에 계정에는 아무것도 없습니다. `InsuranceAPI`, `ClaimsAgent`및 3개의 `Claims*` 추론 대상은 보험 청구 애플리케이션에 대해 생성된 이름이며, 모든 예제가 하나의 도구, 파라미터 유형 및 보안 주체 세트를 공유할 수 있도록 선택됩니다. 예제를 조정할 때 자체 게이트웨이 ARN, 대상 이름 및 도구 이름을 대체합니다.

모든 예제는이 게이트웨이에 대한 요청을 승인합니다.

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

예제를 조정할 때이 ARN을 자체 게이트웨이의 ARN으로 바꿉니다. 게이트웨이는 보험 청구 애플리케이션에 속하며 AgentCore의 정책이 승인하는 모든 대상 유형을 포함하는 5개의 대상, 즉 모델 컨텍스트 프로토콜(MCP) 대상 1개, AgentCore 런타임 대상 1개, 추론 대상 3개가 있습니다.

이 페이지에서는 예제에서 참조하는 작업 이름, 도구 스키마, 요청 본문 및 보안 주체를 설명합니다. 한 번 읽으면 나머지 예제에서는 더 이상 설정할 필요가 없습니다.

## 작업 이름
<a name="example-policies-reference-actions"></a>

정책에 작성하는 작업 이름은 요청을 처리하는 대상의 유형에 따라 다릅니다. MCP를 제외한 모든 항목의 경우 호출자가 사용한 메서드와 경로에 따라 달라집니다.


| 대상 | 유형 | 작업 이름 | 
| --- | --- | --- | 
|  `InsuranceAPI`  | MCP |  `AgentCore::Action::"InsuranceAPI___file_claim"` (도구당 작업 1개) | 
|  `ClaimsAgent`  | AgentCore 런타임 |  `AgentCore::Action::"ClaimsAgent___POST:/invocations"`  | 
|  `ClaimsChat`  | Inference |  `AgentCore::Action::"ClaimsChat___POST:/v1/chat/completions"`  | 
|  `ClaimsResponses`  | Inference |  `AgentCore::Action::"ClaimsResponses___POST:/v1/responses"`  | 
|  `ClaimsMessages`  | Inference |  `AgentCore::Action::"ClaimsMessages___POST:/v1/messages"`  | 

MCP 대상은 도구당 하나의 작업을 생성하므로 정책에서 단일 도구의 이름을 지정할 수 있습니다. 다른 모든 대상 유형은 메서드 및 경로 조합당 하나의 작업을 생성하므로 정책은 개별 기능이 아닌 대상과 경로의 이름을 지정합니다.

### 추론 대상 및 API 경로
<a name="example-policies-reference-inference-paths"></a>

추론 대상은 하나의 API 셰이프에 대해 구성되므로 둘 이상의 추론 API를 제공하는 게이트웨이에는 API당 하나의 대상이 있습니다. 따라서 참조 게이트웨이에는 3개가 있습니다. 각 에는 서로 다른 요청 본문이 있으므로 한에 대해 작성된 정책은 다른에 전달되지 않습니다.


| 대상 | API 경로 | 봉투 | 
| --- | --- | --- | 
|  `ClaimsChat`  |  `POST /v1/chat/completions`  | OpenAI 채팅 완료 | 
|  `ClaimsResponses`  |  `POST /v1/responses`  | OpenAI 응답 | 
|  `ClaimsMessages`  |  `POST /v1/messages`  | Anthropic 메시지 | 

게이트웨이는 사용 가능한 모델을 나열`GET /v1/models`하는 도 노출할 수 있습니다. 요청 본문이 없으므로의 정책은 보안 주체, 작업 및 리소스에서만 일치할 `ClaimsChat___GET:/v1/models` 수 있습니다.

**중요**  
추론을 완전히 관리하려면 게이트웨이의 모든 추론 작업에 대한 정책을 작성합니다. 정책 이름 지정은 `/v1/responses` 및 `/v1/messages` 대상을 주소 없는 상태로만 `ClaimsChat___POST:/v1/chat/completions` 남기고, 3개의 봉투는 프롬프트를 다른 위치에 배치하므로 한에 대해 작성된 조건은 다른에 대해 축어적으로 재사용할 수 없습니다. 자세한 내용은 [경로별 추론 요청 본문](#example-policies-reference-inference-bodies)을 참조하세요.

HTTP 프록시 대상을 포함한 전체 규칙은 [대상 유형별 작업 이름을](policy-scope.md#policy-guardrails-action-naming) 참조하세요.

## InsuranceAPI 대상의 MCP 도구
<a name="example-policies-reference-tools"></a>

`InsuranceAPI` 대상은 8개의 도구를 노출합니다. 각 파라미터의 Cedar 유형은 JSON 스키마 유형에서 따릅니다. 이 유형은 조건의 파라미터에 사용할 수 있는 연산자를 결정합니다. 자세한 내용은 [조건의 파라미터 유형을](#example-policies-types) 참조하세요.

InsuranceAPI\_\_\_get\_contract  
적용 범위 및 기간 날짜와 같은 보험 계약 세부 정보를 검색합니다.  
 **파라미터:**   
+  `contractId` (문자열, 필수) - 보험 계약 식별자

InsuranceAPI\_\_\_file\_claim  
보험 청구서를 제출합니다.  
 **파라미터:**   
+  `contractId` (문자열, 필수) - 보험 계약 식별자
+  `claimType` (문자열, 필수) - 클레임 유형: `health`, `property`또는 `auto` 
+  `amount` (숫자, 필수) - 클레임 금액
+  `policyTermMonths` (정수, 필수) - 정책 기간, 월 단위
+  `description` (문자열, 선택 사항) - 클레임 설명

InsuranceAPI\_\_\_update\_coverage  
정책 적용 범위를 업데이트합니다.  
 **파라미터:**   
+  `contractId` (문자열, 필수) - 보험 계약 식별자
+  `coverageType` (문자열, 필수) - `liability` 또는와 같은 적용 범위 유형 `collision` 
+  `newLimit` (숫자, 필수) - 새 적용 범위 제한

InsuranceAPI\_\_\_get\_claim\_status  
클레임 상태를 확인합니다.  
 **파라미터:**   
+  `claimId` (문자열, 필수) - 클레임 식별자

   **반환:** `claimId` (문자열), `status` (문자열)

InsuranceAPI\_\_\_calculate\_premium  
프리미엄을 계산합니다.  
 **파라미터:**   
+  `coverageType` (문자열, 필수) - 적용 범위 유형
+  `coverageAmount` (숫자, 필수) - 적용 범위 금액
+  `riskFactors` (객체, 선택 사항) - 위험 평가 요소, `region` (문자열) 멤버 및 `priorClaims` (정수) 멤버 포함

InsuranceAPI\_\_\_approve\_claim  
제출된 클레임을 승인합니다. 임시 예제에서는이 도구를 지급 앞에 와야 하는 승인으로 사용합니다.  
 **파라미터:**   
+  `claimId` (문자열, 필수) - 클레임 식별자
+  `approved` (부울, 필수) - 클레임 승인 여부
+  `approvedAmountCents` (정수, 필수) - 승인된 금액, 센트 단위

   **반환:** `claimId` (문자열), `approved` (부울), `approvedAmountCents` (정수)

InsuranceAPI\_\_\_disburse\_pay  
승인된 클레임에 대한 결제를 지불합니다.  
 **파라미터:**   
+  `claimId` (문자열, 필수) - 클레임 식별자
+  `amountCents` (정수, 필수) - 지출할 금액, 센트 단위

   **반환:** `claimId` (문자열), `status` (문자열), `amountCents` (정수)

InsuranceAPI\_\_\_delete\_claim  
클레임 레코드를 영구적으로 삭제합니다. 예제에서는이 도구를 대부분의 보안 주체가 도달해서는 안 되는 민감한 작업으로 사용합니다.  
 **파라미터:**   
+  `claimId` (문자열, 필수) - 클레임 식별자

## 런타임 대상에 대한 요청 본문
<a name="example-policies-reference-bodies"></a>

런타임 대상은 하나의 작업으로 승인되며 선언된 도구 인수 세트가 아닌 요청 본문을 `context.input` 보유합니다.

 `ClaimsAgent___POST:/invocations`   
클레임 어시스턴트를 호스팅하는 AgentCore 런타임 대상입니다.  
 **요청 본문:**   
+  `prompt` (문자열) - 에이전트에 대한 사용자의 메시지
+  `sessionAttributes` (객체, 선택 사항) - 발신자 제공 속성

   **응답 본문:** `completion` (문자열)

**중요**  
런타임 대상의 경우 정책이 읽을 수 있는 필드는 런타임이 실제로 보내는 것이 아니라 **게이트웨이 대상에 선언된 OpenAPI 스키마**에서 가져옵니다. 스키마가 주소를 지정할 수 없다고 선언하는 필드는 스키마가 나열하는 응답 속성에 대해서만 `context.output.<field>` 작동하며 임시 조건자의 `output.<field>`에도 동일하게 적용됩니다.  
런타임 필드의 조건이 선언되지 않은 상태로 거부되는 경우 런타임 코드 대신 대상의 스키마를 확인합니다.

## 경로별 추론 요청 본문
<a name="example-policies-reference-inference-bodies"></a>

추론 대상의 경우는 호출자가 호출한 API의 요청 본문을 `context.input` 보유합니다. 세 봉투는 추론 대상에 대해 조건 또는 가드레일 데이터 경로를 작성하기 전에 알아야 할 가장 중요한 단일 항목인 대화 텍스트를 서로 다른 구조에 배치합니다.

 `ClaimsChat___POST:/v1/chat/completions`   
OpenAI 채팅 완료. 대화는 메시지 객체의 배열이며, 시스템 프롬프트는가 포함된 메시지입니다`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?" }
  ]
}
```
 **응답 본문:** `choices` (배열), `message` 객체가 있는 각 항목 `role` 및 `content` 

 `ClaimsResponses___POST:/v1/responses`   
OpenAI 응답. 프롬프트는 배열을 각각 보유하는 항목 목록 **또는** 베어 문자열일 수 있는 단일 `input` 멤버입니다`content`. 시스템 프롬프트는 별도의 `instructions` 멤버입니다.  

```
{
  "model": "openai.gpt-oss-120b-1:0",
  "instructions": "You are a claims assistant.",
  "input": "What is the status of claim C-1001?"
}
```
 **응답 본문:** `output` (배열), 블록 `content` 배열이 있는 각 항목 `text` 

 `ClaimsMessages___POST:/v1/messages`   
Anthropic 메시지. 대화는 문자열이거나 입력된 블록의 `messages` 배열일 `content` 수 있는 배열입니다. 시스템 프롬프트는 메시지가 아닌 최상위 `system` 멤버입니다.  

```
{
  "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?" }
  ]
}
```
 **응답 본문:** 보유 블록의 `content` (배열) `text` 

### 각 경로의 텍스트 위치
<a name="example-policies-reference-inference-fields"></a>

다음 표에는 양방향으로 각 경로에 있는 대화 텍스트의 위치가 나와 있습니다. 호출자 또는 모델이 실제로 말한 내용을 가드레일로 가리켜야 할 때마다 사용합니다.


| API 경로 | 인바운드 텍스트 | 아웃바운드 텍스트 | 
| --- | --- | --- | 
|  `/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`  | 

두 경로는 와이어 형식이 다르기 때문에 둘 이상의 인바운드 위치를 나열합니다. 에서 `/v1/responses``input`는 베어 문자열 또는 항목 목록이므로 텍스트는 한 경우 `input`에, 다른 경우 `input[*].content[*].text`에 있습니다. 에서 `/v1/messages`메시지의 `content`는 문자열이거나 입력된 블록의 배열입니다. 두 셰이프의 이름을 모두 지정하면 호출자가 어떤 셰이프를 보냈는지 알 필요 없이 와이어 형식 중 하나를 사용할 수 있습니다.

**중요**  
이러한 위치는 배열 및 레코드 안에 있으므로 베어 `context.input.<field>` 경로로 연결할 **수 없습니다**. `context.input.messages`는 텍스트가 `Set<record>`아닌 이고 Dogwood에는 배열 프로젝션 연산자가 없으므로 필드 경로에서 `messages[*].content` 구문 분석 오류가 발생합니다. 대신 접`$`두사가 붙은 JSONPath 문자열을 사용하여 가드레일 데이터 경로에 도달합니다. 자세한 내용은 [ JSONPath를 사용하여 배열 내부의 텍스트에 도달을 참조하세요](example-policies-guardrails.md#example-policies-guardrails-jsonpath).  
일반적인 Cedar 조건의 경우 스칼라 멤버만 사용할 수 있습니다. `context.input.model`는 `String` 이고 작동하지만는 전혀 비교하거나 패턴 일치할 수 `context.input.messages` 없습니다.

## 보안 주체
<a name="example-policies-reference-principals"></a>

보안 주체 엔터티 유형은 게이트웨이가 인바운드 호출자를 인증하는 방법에 따라 달라집니다. 이 예제에서는 패턴에서 호출하는 유형을 사용하며 대부분의 패턴은 둘 다와 함께 작동합니다.

AgentCore::OAuthUser  
게이트웨이는 JWT 권한 부여자를 사용합니다. 개체 ID는 토큰의 `sub` 클레임이며 토큰의 다른 클레임은 `principal.hasTag("<claim>")` 및를 통해 태그로 사용할 수 있습니다`principal.getTag("<claim>")`. 이 예제에서는 `username`, 및 `role`라는 세 가지 클레임을 사용합니다`scope`.

AgentCore::IamEntity  
게이트웨이는를 사용합니다`AWS_IAM`. 엔터티 ID는 세션 이름이 제거된 호출자의 ARN이므로 수임된 역할은 로 표시됩니다`arn:aws:sts::<account>:assumed-role/<role-name>`. 이 양식은 세션 간에 안정적이므로와 일치`principal ==`시키거나 역할 패밀리를와 일치시킬 수 있습니다`principal.id like`.

보안 주체 속성의 전체 목록과 클레임이 태그에 매핑되는 방법은 보안 [주체](policy-scope.md#policy-principal)를 참조하세요.

## 조건의 파라미터 유형
<a name="example-policies-types"></a>

도구 파라미터의 JSON 스키마 유형에 따라 Cedar 유형이 결정되고 Cedar 유형에 따라 유효한 연산자가 결정됩니다. 이 문제가 발생하면 검증에 실패하거나 런타임에 모든 요청을 거부하는 정책이 생성되므로 조건을 작성하기 전에 파라미터의 유형을 확인하세요.


| JSON 스키마 유형 | Cedar 유형 | 비교 방법 | 
| --- | --- | --- | 
|  `string`  |  `String`  |  `==`, `like`, 및 `!=`를 사용한 멤버십 설정 `.contains()`  | 
|  `integer`  |  `Long`  |  `==`, `<`, `⇐`, `>`, 정수 리터럴 `>=` 포함 | 
|  `number`  |  `decimal`  | 각각 `decimal("…​")` 리터럴에 대해 `.lessThan()`, `.lessThanOrEqual()``==`, `.greaterThan()`, `.greaterThanOrEqual()`, 및 만. Cedar에는 부동 소수점 리터럴`decimal`에 대한 `<` 또는 `>` 연산자가 없습니다. | 
|  `boolean`  |  `Bool`  |  `==`, 및 조건에서 직접 사용 | 
|  `object`  |  `Record`  | 를 사용하여 멤버에 액세스하고 `.`를 사용하여 멤버를 테스트합니다. `has`  | 
|  `array`  |  `Set`  |  `.contains()`, `.containsAll()`, `.containsAny()`  | 
|  `null`  |  `Entity`  | 비교할 수 없습니다. `null` 인수는에서 생략`context.input`되므로를 사용하여 부재 여부를 테스트합니다. `!(context.input has <field>)`  | 

이들은 Cedar의 고유한 유형 이름이며 생성된 스키마가 사용하는 이름입니다. 각 변환에 대한 참고 사항을 포함한 전체 매핑은 [컨텍스트](policy-schema-constraints.md#policy-context)를 참조하세요.

### 숫자 파라미터
<a name="example-policies-numeric"></a>

숫자는 서비스가 거부하는 형식으로 조건을 작성할 가능성이 가장 높은 곳입니다. 비교를 작성하기 전에 파라미터의 유형과 유형이 지원하는 연산자를 확인합니다.

 **는 Cedar이 `integer` 됩니다`Long`.** 일반 연산자 및 정수 리터럴과 비교합니다.

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

 **는 Cedar이 `number` 됩니다`decimal`.** Cedar는 `<`에 대해 `⇐`, `>`, 또는 `>=` 연산자를 정의하지 `decimal` 않으며 부동 소수점 리터럴이 없으므로 비교 방법과 따옴표로 묶인 `decimal("…​")` 리터럴을 사용합니다.

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

`context.input.amount > 1000.00` 및 `context.input.amount < 1000` 모두 유효하지 않습니다. 첫 번째 에는 유형에 대한 연산자가 없으며 두 번째는를 `decimal`와 비교합니다`Long`.

 **`temporal { }` 블록 내에서 주문하려면가 필요합니다`integer`.** `decimal`는 순서 비교에서 거부되며 도 마찬가지입니다`string`. 합계에는 동일한 요구 사항이 있습니다. 에는 `integer` 합계가 `sum` 필요합니다. 양쪽이 동일한 유형인 경우 평등(, `==``!=`)은 제한되지 않습니다. 자세한 내용은 [임시 정책 예제](example-policies-temporal.md)를 참조하세요.

이 서비스는 정책을 생성할 때 이러한 종류의 유형 오류를 보고합니다. 메시지는와 같은 선 및 열 포인터 `unexpected type: expected Long but saw decimal`또는 `temporal` 블록 `comparison requires numeric operands on both sides` 내부를 사용하여 예상 및 실제 유형의 이름을 지정합니다.

**작은 정보**  
시간 정책이 도구 스키마`integer`에서 합계 또는 임계값으로 사용해야 하는 모든 값을 모델링합니다. 따라서 참조 게이트웨이는 두 가지 방법으로 화폐를 표시합니다. 규칙은 point-in-time 비교이므로 `number`는를 `amount`로 `file_claim` 사용합니다. `approve_claim`는 정수를 `approvedAmountCents` 사용하고는 정수를 `disburse_payment` 사용합니다. 임시 예제는 이를 집계하기 `amountCents`때문입니다. 비용을 정수 마이너 단위로 나타내는 것은 시간 정책 값이 합산되어야 하는 모든 도구에 대해 채택할 가치가 있습니다.

소수 정밀도 제한 및 기타 스키마 제약 조건은 [제약 및 할당량을 참조하세요](policy-schema-constraints.md).

호출자가 파라미터를 생략`context.input`하면에서 선택적 파라미터가 없으므로 읽기 `has` 전에를 사용하여 멤버를 테스트합니다.

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

가드는 권고 대신 필요합니다. 선택적 속성을 읽지 않으면를 사용한 정책 생성에 실패`unable to guarantee safety of access to optional attribute`하고 실패는 비동기식입니다. 202 뒤에가 옵니다`CREATE_FAILED`. 스키마 마크에 필요한 파라미터에는 가드가 필요하지 않습니다.

유형 불일치는 동일한 방식으로 실패합니다. 문자열 배열`.contains(1)`에서 행과 열 포인터가 `the types Long and String are not compatible`있는를 보고합니다.