DataStrict
Integrations

Integrations

AWS

Run the DataStrict gateway inside your AWS account and govern Amazon Bedrock traffic without data leaving your VPC.

Overview

DataStrict runs inside your own AWS account. The gateway deploys as a container on ECS, EKS, or Fargate in your VPC, so governed prompts, model responses, and the audit Ledger never leave your security boundary.

Once it is in-path, every call to Amazon Bedrock - and any other model you route through it - is evaluated against policy before the model ever answers.

How it works

Your application talks to the DataStrict gateway instead of talking to Bedrock directly. The gateway evaluates each request against your active policies, redacts or blocks what it must, forwards what is allowed, and writes the decision to the Ledger in your own Postgres (RDS or Aurora).

Identity comes from the IAM role or workload identity of the calling service, so policy decisions are bound to who is asking and for what purpose.

Connect

Deploy the gateway image to ECS or EKS, give it an IAM role scoped to the Bedrock models it may reach, and point your SDK base URL at the gateway. No application code changes beyond the base URL.

# datastrict.yaml
gateway:
  provider: bedrock
  region: us-east-1
  ledger: postgres://ledger.internal:5432/datastrict
policy:
  source: ./policies   # policy-as-code, reviewed in your repo

What you can enforce

  • Bedrock prompts and responses, evaluated against policy before the model answers.
  • PII and secrets redacted at the boundary so they never enter a prompt or a vendor model.
  • Agent and tool access denied by default - a policy must explicitly allow each action.
  • Every decision written to a hash-chained Ledger in your own account, never ours.

Tip · Air-gapped and BYOC

The same container runs fully self-hosted, private-cloud, or air-gapped. See the deployment page for network topologies.

Was this page helpful?