AWS Bedrock integration

Action security for AWS Bedrock.

Add action policy around Bedrock runtime calls and application handlers.

Get the package and source.

Connect the execution boundary.

Use documented runtime wrappers and application-controlled action-group handlers. The wrapper cannot govern hidden execution paths inside a managed service.

An example to test

A cloud assistant requests customer metadata beyond the support case. Apply policy before the application-owned handler accesses or sends it.

Illustrative workflow, not a customer deployment or a measured result.

Before connecting live policy

  1. Identify the handler that actually performs the side effect.
  2. Provide trusted identity, purpose and final action arguments.
  3. Configure the tenant’s assigned runtime and keep API credentials server-side.
  4. Test allowed, blocked and unavailable paths before production.

Integration example

Adapt this existing SDK pattern to your application. Names such as the agent, handler and session refer to your own objects. Follow the package documentation for compatible versions and complete setup.

# Install AWS Bedrock support.
python -m pip install "agenticdome-python-sdk[bedrock]"

from agenticdome_sdk.aws_bedrock import AgenticDomeAWSBedrockFirewall

firewall = AgenticDomeAWSBedrockFirewall()
response = await firewall.converse_securely(
    bedrock_runtime_client=bedrock, model_id=model_id, messages=messages,
    agent_id="support_bedrock_agent", session_id=session_id
)

agenticdome-demo --framework bedrock --scenario metadata_exfil

Python demo commands evaluate fixed inputs against a bundled local policy; they do not instantiate the selected framework or prove a live integration. The TypeScript client and OpenClaw runtime plugin need their documented tenant configuration.

See the decision before the action.

Try a local scenario, then bring your workflow to a deployment review. Start with one agent and one tool, and see exactly where the action can be stopped.