WAF-AGN-050 – Safety & Guardrails

Pillar: Agentic | Severity: High | Category: Logging Monitoring | Automatable: High

Description

Fail-safe, alignment, and verification mechanisms MUST be in place. Content filters MUST be configured to block inappropriate content. Action boundaries MUST prevent agents from performing unauthorized actions. Human-in-the-loop MUST be configured for sensitive decisions. Guardrails MUST align with organizational values.

Rationale

Risk	Description
Risk	Misaligned agents can optimize for the wrong objectives and cause business or safety harm.
Risk	Missing verification loops let erroneous agent outputs reach production systems.

Risk

Description

Risk

Misaligned agents can optimize for the wrong objectives and cause business or safety harm.

Risk

Missing verification loops let erroneous agent outputs reach production systems.

Requirements

Fail-safe, alignment, and verification mechanisms MUST be in place.
Content filters MUST be configured to block inappropriate content.
Action boundaries MUST prevent agents from performing unauthorized actions.
Human-in-the-loop MUST be configured for sensitive decisions.
Guardrails MUST align with organizational values.

Implementation Guidance

Document the requirement in a version-controlled policy or standard.
Assign ownership and establish a review cadence (e.g., quarterly).
Implement the required configuration as code in Terraform or equivalent IaC.

Maturity Levels

Level	Name	Criteria
L1	Ad hoc – control not consistently applied	* Manual evidence exists for some workloads, but coverage is unknown.
L2	Standardised – policy defined and communicated	* A version-controlled policy, ADR, or standard describes the requirement.
L3	Integrated – automated validation in CI/CD	* Terraform checks run automatically on pull requests and report results.
L4	Auditable – metrics and exceptions tracked	* Control coverage, failures, and approved exceptions are reported quarterly.
L5	Optimised – continuous improvement based on data	* Control effectiveness is measured and iteratively improved.

Level

Name

Criteria

Ad hoc – control not consistently applied

* Manual evidence exists for some workloads, but coverage is unknown.

Standardised – policy defined and communicated

* A version-controlled policy, ADR, or standard describes the requirement.

Integrated – automated validation in CI/CD

* Terraform checks run automatically on pull requests and report results.

Auditable – metrics and exceptions tracked

* Control coverage, failures, and approved exceptions are reported quarterly.

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

waf-agn-050.tf.aws.content-filters-enabled

Engine: terraform | Provider: aws | Automated: Yes

AWS Bedrock agents must have content filters configured

AWS Bedrock agents must have content filtering enabled via guardrails. Filters must block harmful, offensive, or inappropriate content according to organizational policy.

Scope: resource — aws_bedrock_guardrail, aws_bedrockagent

Assertions: * name not empty — Content filters (guardrails) must be configured.

Remediation: Create and configure AWS Bedrock guardrails with content filtering. Define content policies for hate speech, violence, sexual content, and harmful activity. Apply guardrails to all agents.

Compliant

resource "aws_bedrock_guardrail" "organizational_guardrail" {
  name = "organizational-guardrail"

  blocked_input_messages = [{
    text = "hate-speech"
  }]

  blocked_output_messages = [{
    text = "hate-speech"
  }]

  # Content filters configured
}

resource "aws_bedrockagent" "filtered_agent" {
  agent_name = "content-filtered-agent"

  guardrail_configuration {
    guardrail_arn = aws_bedrock_guardrail.organizational_guardrail.arn
    guardrail_version = "DRAFT"
  }
}

Non-Compliant

resource "aws_bedrockagent" "unfiltered" {
  agent_name = "no-content-filter"
  # No guardrail configured
  # WAF-AGN-050 Violation
}

waf-agn-050.tf.aws.action-boundaries-configured

Engine: terraform | Provider: aws | Automated: Yes

Agent action boundaries must be configured

Agents must have action boundaries defined via IAM roles and tool schemas. Agents must not be able to perform actions outside their scope. Maximum token limits and output lengths must be configured.

Scope: resource — aws_iam_role, aws_bedrockagent

Assertions: * name not empty — Action boundaries (IAM policies) must be configured.

Remediation: Configure IAM roles with least-privilege permissions for agent actions. Define strict tool schemas limiting what tools agents can use. Set output token limits and input length constraints in agent configuration.

Compliant

resource "aws_iam_role" "agent_role" {
  name = "agent-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Service = "bedrock.amazonaws.com"
      }
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy" "agent_limits" {
  name = "agent-limits"
  role = aws_iam_role.agent_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = [
        "s3:GetObject",
        "s3:ListBucket"
      ]
      Resource = [
        "arn:aws:s3:::allowed-bucket/*"
      ]
    }]
  })
}

Non-Compliant

resource "aws_iam_role" "unlimited_role" {
  name = "unlimited-agent-role"
  # No policy restrictions
  # WAF-AGN-050 Violation
}

waf-agn-050.tf.aws.human-in-the-loop-configured

Engine: terraform | Provider: aws | Automated: Yes

Human-in-the-loop must be configured for sensitive decisions

For high-risk agent decisions (financial, legal, personal data), human approval MUST be required. The human-in-the-loop workflow must be configured via AWS Bedrock or external approval system.

Scope: resource — aws_bedrockagent

Assertions: * agent_name not empty — Human-in-the-loop must be configured for sensitive decisions.

Remediation: Configure human-in-the-loop approval workflows for sensitive agent actions. Use AWS Bedrock’s approval feature or integrate with an external approval system (ServiceNow, Jira, custom). Define decision types requiring human review.

Compliant

resource "aws_bedrockagent" "hitable_agent" {
  agent_name = "human-in-loop-agent"

  human_interaction_configuration {
    human_interpretation_prompt = "Review agent decision for accuracy"
    human_interpretation_timeout = 3600
    human_interpretation_output_context_name = "approval"
  }
}

Non-Compliant

resource "aws_bedrockagent" "no_huawei" {
  agent_name = "fully-automated-agent"
  # No human-in-the-loop for sensitive decisions
  # WAF-AGN-050 Violation
}

waf-agn-050.tf.azurerm.content-safety-policy

Engine: terraform | Provider: azurerm | Automated: Yes

Azure AI Content Safety must have fail-safe filters configured

Azure AI Content Safety accounts must have content filters configured to block hate, violence, sexual, and self-harm content for agent outputs.

Scope: resource — azurerm_cognitive_account

Assertions: * kind equals ContentSafety — A Content Safety cognitive account must exist for fail-safe filtering. * sku_name not empty — Content Safety account must have a configured SKU.

Remediation: Deploy azurerm_cognitive_account with kind "ContentSafety" and configure content filter policies. Apply filters to agent deployments.

Compliant

resource "azurerm_cognitive_account" "content_safety" {
  name                = "content-safety-account"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  kind                = "ContentSafety"
  sku_name            = "S0"
}

# Content filter policy applied at application level or via azurerm_cognitive_account_content_filter

Non-Compliant

resource "azurerm_cognitive_account" "content_safety" {
  name                = "content-safety-account"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  kind                = "ContentSafety"
  sku_name            = "S0"
  # No content filter policy applied
  # WAF-AGN-050 Violation
}

waf-agn-050.tf.google.vertex-safety-filters

Engine: terraform | Provider: google | Automated: Yes

GCP Vertex AI agents must have safety filters configured

GCP Vertex AI agents must have safety filter settings configured to block harmful content categories and prevent unauthorized actions.

Scope: resource — google_vertex_ai_agent

Assertions: * safety_settings attribute exists — Vertex AI agent must have safety_settings configured.

Remediation: Configure google_vertex_ai_agent with safety_settings block defining thresholds for HATE_SPEECH, HARASSMENT, SEXUALLY_EXPLICIT, and DANGEROUS_CONTENT.

Compliant

resource "google_vertex_ai_agent" "safe_agent" {
  display_name = "safe-agent"

  safety_settings {
    category  = "HATE_SPEECH"
    threshold = "BLOCK_LOW_AND_ABOVE"
  }

  safety_settings {
    category  = "DANGEROUS_CONTENT"
    threshold = "BLOCK_MEDIUM_AND_ABOVE"
  }
}

Non-Compliant

resource "google_vertex_ai_agent" "unsafe_agent" {
  display_name = "unsafe-agent"
  # No safety_settings configured
  # WAF-AGN-050 Violation
}

waf-agn-050.tf.stackit.agentic-failsafe-verified

Engine: terraform | Provider: stackit | Automated: Yes

Fail-safe, alignment, and verification mechanisms for stackit

Fail-safe, alignment, and verification mechanisms must be documented in IaC via a agentic-failsafe-verified tag/label on stackit_project. This validates the control is tracked as code.

Scope: resource — stackit_project

Assertions: * labels key exists — stackit_project is missing the agentic-failsafe-verified tag/label.

Remediation: Add a agentic-failsafe-verified tag/label to the stackit_project resource to show the stackit implementation of WAF-AGN-050 is tracked in IaC.

Compliant

resource "stackit_project" "example" {
  labels = {
    agentic-failsafe-verified = "true"
  }
}

Non-Compliant

resource "stackit_project" "example" {
  # Missing agentic-failsafe-verified labels
}

waf-agn-050.tf.ovh.agentic-failsafe-verified

Engine: terraform | Provider: ovh | Automated: Yes

Fail-safe, alignment, and verification mechanisms for ovh

Fail-safe, alignment, and verification mechanisms must be documented in IaC via a agentic-failsafe-verified tag/label on ovh_cloud_project. This validates the control is tracked as code.

Scope: resource — ovh_cloud_project

Assertions: * tags key exists — ovh_cloud_project is missing the agentic-failsafe-verified tag/label.

Remediation: Add a agentic-failsafe-verified tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-AGN-050 is tracked in IaC.

Compliant

resource "ovh_cloud_project" "example" {
  tags = {
    agentic-failsafe-verified = "true"
  }
}

Non-Compliant

resource "ovh_cloud_project" "example" {
  # Missing agentic-failsafe-verified tags
}

waf-agn-050.tf.hcloud.agentic-failsafe-verified

Engine: terraform | Provider: hcloud | Automated: Yes

Fail-safe, alignment, and verification mechanisms for hcloud

Fail-safe, alignment, and verification mechanisms must be documented in IaC via a agentic-failsafe-verified tag/label on hcloud_server. This validates the control is tracked as code.

Scope: resource — hcloud_server

Assertions: * labels key exists — hcloud_server is missing the agentic-failsafe-verified tag/label.

Remediation: Add a agentic-failsafe-verified tag/label to the hcloud_server resource to show the hcloud implementation of WAF-AGN-050 is tracked in IaC.

Compliant

resource "hcloud_server" "example" {
  labels = {
    agentic-failsafe-verified = "true"
  }
}

Non-Compliant

resource "hcloud_server" "example" {
  # Missing agentic-failsafe-verified labels
}

Evidence

Kind Required Description

Kind	Required	Description
`iac`	Required	Terraform configuration implementing the control.
`governance`	Required	Policy, ADR, or standard documenting the requirement.
`config`	Optional	Cloud console or API output confirming runtime state.

iac

Required

Terraform configuration implementing the control.

governance

Required

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

Related Controls

Framework	Controls
ISO 27001:2022	* A.8.2 – Privileged access rights * A.8.3 – Information access restriction * A.13.1.1 – Control of information in sessions
ISO 27017	* CLD.9.5 – Segregation in virtual computing environments
CIS Controls v8	* CIS 13 – Content Filtering
SOC 2 Type II	* CC4.1 – Monitoring activities * CC6.1 – Logical access security
NIST SP 800-53	* SI-4 – Information system monitoring * SI-5 – Malicious code protection
NIST CSF 2.0	* DE.CM – Continuous monitoring * DE.DP – Data protection
GDPR	* Art. 32 – Security of processing * Art. 5(1)(f) – Integrity and confidentiality
PCI DSS v4.0	* Req 6.4 – Secure development lifecycle * Req 6.5 – Secure coding practices
CSA STAR	* CCM Security Incident Management
BSI C5:2020	* OPS-01 – Operational monitoring * OPS-02 – Operational control
TISAX	* Information security – Monitoring and logging
ANSSI SecNumCloud	* Domain – Security monitoring
BIO	* BIO – Monitoring en beveiliging
ENS High	* op.exp.6 – Gestión de cambios * op.sec.7 – Protección contra malware
UK NCSC CAF	* A4 – Policy and assurance
FedRAMP	* SI-4, SI-5 (Moderate baseline)
CMMC 2.0	* SI.L2-3.8.1 – Limit information system use
IT-Grundschutz	* ORP.1 – Organisation
IRAP	* ISM – Content filtering and protection
CCCS PBMM	* SI-4 – Security monitoring
MAS TRM	* Ch.9 – Change management
ISMAP	* Security monitoring controls
FISC	* Technical measures – Security monitoring

Framework

Controls

ISO 27001:2022

* A.8.2 – Privileged access rights * A.8.3 – Information access restriction * A.13.1.1 – Control of information in sessions

ISO 27017

* CLD.9.5 – Segregation in virtual computing environments

CIS Controls v8

* CIS 13 – Content Filtering

SOC 2 Type II

* CC4.1 – Monitoring activities * CC6.1 – Logical access security

NIST SP 800-53

* SI-4 – Information system monitoring * SI-5 – Malicious code protection

NIST CSF 2.0

* DE.CM – Continuous monitoring * DE.DP – Data protection

GDPR

* Art. 32 – Security of processing * Art. 5(1)(f) – Integrity and confidentiality

PCI DSS v4.0

* Req 6.4 – Secure development lifecycle * Req 6.5 – Secure coding practices

CSA STAR

* CCM Security Incident Management

BSI C5:2020

* OPS-01 – Operational monitoring * OPS-02 – Operational control

TISAX

* Information security – Monitoring and logging

ANSSI SecNumCloud

* Domain – Security monitoring

BIO

* BIO – Monitoring en beveiliging

ENS High

* op.exp.6 – Gestión de cambios * op.sec.7 – Protección contra malware

UK NCSC CAF

* A4 – Policy and assurance

FedRAMP

* SI-4, SI-5 (Moderate baseline)

CMMC 2.0

* SI.L2-3.8.1 – Limit information system use

IT-Grundschutz

* ORP.1 – Organisation

IRAP

* ISM – Content filtering and protection

CCCS PBMM

* SI-4 – Security monitoring

MAS TRM

* Ch.9 – Change management

ISMAP

* Security monitoring controls

FISC

* Technical measures – Security monitoring