create_policy
async
¶
create_policy(
name: PolicyName,
definition: PolicyDefinition,
policy_engine_id: ResourceId,
*,
config_overrides: Optional[AsyncBedrockAgentCoreControlClientConfig] = None,
description: Optional[Description] = None,
validation_mode: Optional[PolicyValidationMode] = None,
enforcement_mode: Optional[EnforcementMode] = None,
client_token: Optional[ClientToken] = None,
) -> CreatePolicyResponse
Creates a policy within the AgentCore Policy system. Policies provide real-time, deterministic control over agentic interactions with AgentCore Gateway. Using Cedar or Dogwood, you can define fine-grained policies that specify which interactions with Gateway tools are permitted based on input parameters and OAuth claims, ensuring agents operate within defined boundaries and business rules. The policy is validated during creation against the Cedar schema generated from the Gateway's tools' input schemas, which defines the available tools, their parameters, and expected data types. This is an asynchronous operation. Use the GetPolicy operation to poll the status field to track completion.
If the new policy is a temporal policy, creating it invalidates the policy engine's active temporal sessions. For more information about temporal policy sessions, see session-based temporal policies. The policy engine returns an HTTP 409 ConflictException to in-flight sessions. To resume, you must start a new session with a new session ID.
Parameters:
-
name(PolicyName) –The customer-assigned immutable name for the policy. Must be unique within the account. This name is used for policy identification and cannot be changed after creation.
-
definition(PolicyDefinition) –The Cedar or Dogwood policy statement that defines the access control rules. This contains the actual policy logic written in Cedar or Dogwood, specifying effect (permit or forbid), principals, actions, resources, and conditions for agent behavior control.
-
description(Optional[Description], default:None) –A human-readable description of the policy's purpose and functionality (1-4,096 characters). This helps policy administrators understand the policy's intent, business rules, and operational scope. Use this field to document why the policy exists, what business requirement it addresses, and any special considerations for maintenance. Clear descriptions are essential for policy governance, auditing, and troubleshooting.
-
validation_mode(Optional[PolicyValidationMode], default:None) –The validation mode for the policy creation. Determines how Cedar analyzer validation results are handled during policy creation. FAIL_ON_ANY_FINDINGS (default) runs the Cedar analyzer to validate the policy against the Cedar schema and tool context, failing creation if the analyzer detects any validation issues to ensure strict conformance. IGNORE_ALL_FINDINGS runs the Cedar analyzer but allows policy creation even if validation issues are detected, useful for testing or when the policy schema is evolving. Use FAIL_ON_ANY_FINDINGS for production policies to ensure correctness, and IGNORE_ALL_FINDINGS only when you understand and accept the analyzer findings.
-
enforcement_mode(Optional[EnforcementMode], default:None) –The enforcement mode for the policy. Run this policy in
LOG_ONLYmode to collect data on how it affects your application. Once you are satisfied with the data gathered, switch the policy toACTIVE. Defaults toACTIVE. -
policy_engine_id(ResourceId) –The identifier of the policy engine which contains this policy. Policy engines group related policies and provide the execution context for policy evaluation.
-
client_token(Optional[ClientToken], default:None) –A unique, case-sensitive identifier to ensure the idempotency of the request. The Amazon Web Services SDK automatically generates this token, so you don't need to provide it in most cases. If you retry a request with the same client token, the service returns the same response without creating a duplicate policy.
Raises:
-
AccessDeniedException–This exception is thrown when a request is denied per access permissions
-
ConflictException–This exception is thrown when there is a conflict performing an operation
-
InternalServerException–This exception is thrown if there was an unexpected error during processing of request
-
ResourceNotFoundException–This exception is thrown when a resource referenced by the operation does not exist
-
ServiceQuotaExceededException–This exception is thrown when a request is made beyond the service quota
-
ThrottlingException–This exception is thrown when the number of requests exceeds the limit
-
ValidationException–The input fails to satisfy the constraints specified by the service.
-
UnknownServiceError–The service returned an error code this client does not model.
Source code in docs_src/capo_bedrock_agentcore_control/_services/async_bedrock_agent_core_control.py
12311 12312 12313 12314 12315 12316 12317 12318 12319 12320 12321 12322 12323 12324 12325 12326 12327 12328 12329 12330 12331 12332 12333 12334 12335 12336 12337 12338 12339 12340 12341 12342 12343 12344 12345 12346 12347 12348 12349 12350 12351 12352 12353 12354 12355 12356 12357 12358 12359 12360 12361 12362 12363 12364 12365 12366 12367 12368 12369 12370 12371 12372 12373 12374 12375 12376 12377 12378 12379 12380 12381 12382 12383 12384 12385 12386 12387 12388 12389 12390 12391 12392 12393 12394 12395 12396 12397 12398 12399 12400 12401 12402 12403 12404 12405 12406 12407 12408 12409 12410 12411 12412 12413 | |