WAF-AGN-020 – Tool Use Governance

Pillar: Agentic | Severity: High | Category: Agentic Governance | Automatable: High

Description

Not every agent should be able to use every tool. Tool use must be approved, logged, and limited. Agents MUST have explicit tool definitions with approved lists. All tool calls MUST be logged with context, input, output, and timestamp. Rate limits and sandboxing MUST be applied to prevent abuse.

Rationale

Risk	Description
Risk	Overly broad tool permissions allow agents to perform destructive or unauthorized operations.
Risk	Missing permission boundaries at the tool level enable privilege escalation in automated workflows.

Risk

Description

Risk

Overly broad tool permissions allow agents to perform destructive or unauthorized operations.

Risk

Missing permission boundaries at the tool level enable privilege escalation in automated workflows.

Requirements

Not every agent should be able to use every tool.
Tool use must be approved, logged, and limited.
Agents MUST have explicit tool definitions with approved lists.
All tool calls MUST be logged with context, input, output, and timestamp.
Rate limits and sandboxing MUST be applied to prevent abuse.

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-020.tf.aws.bedrock-agent-tools-approved

Engine: terraform | Provider: aws | Automated: Yes

AWS Bedrock agents must have approved tool definitions

AWS Bedrock agents must have explicit tool definitions in their tool schema. Wildcard or unrestricted tools are prohibited. All tools must be from an approved list.

Scope: resource — aws_bedrockagent

Assertions: * tool_schema.tools attribute exists — Agent must have explicit tool definitions. * tool_schema.tools json not contains pattern pattern "name":\\s*"*" — Tools must not use wildcard names like "*". Define specific tools only.

Remediation: Define explicit tools in the aws_bedrockagent resource tool_schema. Use the 'tools' block to specify each allowed tool with name, description, and input schema. Do not use wildcard definitions.

Compliant

resource "aws_bedrockagent" "support_agent" {
  agent_name = "customer-support"

  tool_schema {
    tools = [{
      name = "lookup_customer"
      description = "Look up customer by email"
      input_schema = jsonencode({
        type = "object"
        properties = {
          email = { type = "string" }
        }
        required = ["email"]
      })
    }, {
      name = "check_order_status"
      description = "Check order status"
      input_schema = jsonencode({
        type = "object"
        properties = {
          order_id = { type = "string" }
        }
        required = ["order_id"]
      })
    }]
  }
}

Non-Compliant

resource "aws_bedrockagent" "bad_agent" {
  agent_name = "unrestricted-agent"

  tool_schema {
    tools = [{
      name = "*"
      description = "Allow all tools"
      # WAF-AGN-020 Violation: wildcard tool definition
    }]
  }
}

waf-agn-020.tf.azurerm.ai-tool-filter

Engine: terraform | Provider: azurerm | Automated: Yes

Azure AI services must have content filters and tool restrictions configured

Azure AI services deployments must have content filters and tool usage restrictions configured. Only approved tool functions should be exposed to agents.

Scope: resource — azurerm_cognitive_account, azurerm_cognitive_deployment

Assertions: * network_acls attribute exists — Azure AI services account must have network ACLs restricting access. * sku_name not empty — Azure AI deployment must have a configured SKU.

Remediation: Configure azurerm_cognitive_account with network ACLs and content filters. Use azurerm_cognitive_deployment with strict model settings. Document approved tools in ADR.

Compliant

resource "azurerm_cognitive_account" "ai" {
  name                = "ai-services-account"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  kind                = "OpenAI"
  sku_name            = "S0"

  network_acls {
    default_action = "Deny"
    ip_rules       = ["10.0.0.0/24"]
  }
}

resource "azurerm_cognitive_deployment" "agent" {
  name                 = "agent-deployment"
  cognitive_account_id = azurerm_cognitive_account.ai.id
  model {
    format  = "OpenAI"
    name    = "gpt-4o"
    version = "2024-08-06"
  }
  sku {
    name = "Standard"
    capacity = 1
  }
}

Non-Compliant

resource "azurerm_cognitive_account" "ai" {
  name                = "ai-services-account"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  kind                = "OpenAI"
  sku_name            = "S0"
  # No network ACLs or content filters configured
  # WAF-AGN-020 Violation
}

waf-agn-020.tf.google.vertex-agent-tools-approved

Engine: terraform | Provider: google | Automated: Yes

Google Vertex AI agents must have approved tool definitions

Google Vertex AI agents must have explicit tool function declarations. All tools must reference pre-approved functions with defined schemas.

Scope: resource — google_vertex_ai_agent

Assertions: * function_declarations not empty — Agent must have explicit function declarations.

Remediation: Define function_declarations in the vertex_ai_agent configuration with specific function names, descriptions, and parameter schemas. Do not use generic or wildcard function definitions.

Compliant

resource "google_vertex_ai_agent" "data_analyst" {
  display_name = "data-analyst-agent"

  function_declarations = [{
    name = "query_database"
    description = "Query the analytics database"
    parameters = {
      type = "OBJECT"
      properties = {
        query = {
          type = "STRING"
          description = "SQL query to execute"
        }
      }
      required = ["query"]
    }
  }]
}

Non-Compliant

resource "google_vertex_ai_agent" "unrestricted" {
  display_name = "unrestricted-agent"

  function_declarations = [{
    name = "any_function"
    description = "Any function allowed"
    # WAF-AGN-020 Violation: too permissive
  }]
}

waf-agn-020.tf.aws.tool-call-logging-enabled

Engine: terraform | Provider: aws | Automated: Yes

AWS Bedrock tool calls must be logged

All tool calls made by AWS Bedrock agents MUST be logged to CloudWatch Logs with timestamp, agent ID, tool name, input, output, and duration.

Scope: resource — aws_bedrockagent, aws_cloudwatch_log_group

Assertions: * name not empty — Tool call logging must be configured with a log group.

Remediation: Configure CloudWatch logging for Bedrock agents. Enable 'Inference logs' in the Bedrock console or via API. Create a log group at /aws/bedrock/inference-logs.

Compliant

resource "aws_cloudwatch_log_group" "bedrock_logs" {
  name = "/aws/bedrock/inference-logs"
}

resource "aws_bedrockagent" "agent" {
  agent_name = "loggable-agent"
  # Tool call logging enabled via CloudWatch
}

Non-Compliant

resource "aws_bedrockagent" "no_logging" {
  agent_name = "no-logging-agent"
  # No CloudWatch log group configured
  # WAF-AGN-020 Violation: no tool call logging
}

waf-agn-020.tf.aws.tool-rate-limits-configured

Engine: terraform | Provider: aws | Automated: Yes

Tool call rate limits must be configured for agents

Agents MUST have rate limiting configured to prevent abuse. Maximum tokens per minute and requests per minute should be defined.

Scope: resource — aws_bedrockagent

Assertions: * agent_name not empty — Agent must have rate limiting configuration.

Remediation: Configure rate limits in the Bedrock agent configuration. Use AWS SDK or Console to set maxTokensPerMinute and maxRequestsPerMinute for each agent.

Compliant

resource "aws_bedrockagent" "rate_limited_agent" {
  agent_name = "rate-limited"

  agent_resource_role_arn = aws_iam_role.bedrock.arn

  instruction = "You are a helpful assistant."

  # Rate limiting via IAM policy or external service
  # Tools should be rate-limited via API Gateway or similar
}

Non-Compliant

resource "aws_bedrockagent" "unlimited" {
  agent_name = "unlimited-agent"
  # No rate limiting configured
  # WAF-AGN-020 Violation
}

waf-agn-020.tf.stackit.agentic-access-reviewed

Engine: terraform | Provider: stackit | Automated: Yes

Not every agent should be able to use every tool for stackit

Not every agent should be able to use every tool must be documented in IaC via a agentic-access-reviewed 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-access-reviewed tag/label.

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

Compliant

resource "stackit_project" "example" {
  labels = {
    agentic-access-reviewed = "true"
  }
}

Non-Compliant

resource "stackit_project" "example" {
  # Missing agentic-access-reviewed labels
}

waf-agn-020.tf.ovh.agentic-access-reviewed

Engine: terraform | Provider: ovh | Automated: Yes

Not every agent should be able to use every tool for ovh

Not every agent should be able to use every tool must be documented in IaC via a agentic-access-reviewed 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-access-reviewed tag/label.

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

Compliant

resource "ovh_cloud_project" "example" {
  tags = {
    agentic-access-reviewed = "true"
  }
}

Non-Compliant

resource "ovh_cloud_project" "example" {
  # Missing agentic-access-reviewed tags
}

waf-agn-020.tf.hcloud.agentic-access-reviewed

Engine: terraform | Provider: hcloud | Automated: Yes

Not every agent should be able to use every tool for hcloud

Not every agent should be able to use every tool must be documented in IaC via a agentic-access-reviewed 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-access-reviewed tag/label.

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

Compliant

resource "hcloud_server" "example" {
  labels = {
    agentic-access-reviewed = "true"
  }
}

Non-Compliant

resource "hcloud_server" "example" {
  # Missing agentic-access-reviewed 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.5.15 – Access control
ISO 27017	* CLD.9.5 – Segregation in virtual computing environments
CIS Controls v8	* CIS 5 – Account Management * CIS 6 – Access Control Management
SOC 2 Type II	* CC6.1 – Logical access security * CC6.3 – Authorisation and segregation of duties
NIST SP 800-53	* AC-2 – Account Management * AC-3 – Access Enforcement * AC-6 – Least Privilege
NIST CSF 2.0	* PR.AA-01 – Identities and credentials are managed * PR.AA-05 – Access permissions are managed
GDPR	* Art. 32 – Security of processing * Art. 5(1)(f) – Integrity and confidentiality
PCI DSS v4.0	* Req 7 – Restrict access by business need to know * Req 7.2 – Access based on least privilege
CSA STAR	* CCM IAM-09 – User Access Authorization * CCM IAM-10 – User Access Reviews
BSI C5:2020	* IDM-01 – Identity and access management policy * IDM-03 – Access control and authorisation
TISAX	* Information security – Access rights management
ANSSI SecNumCloud	* Domain – Access management and least privilege
BIO	* BIO – Toegangsrechten en autorisatiebeheer
ENS High	* op.acc.4 – Proceso de gestión de derechos de acceso * op.acc.7 – Gestión de privilegios
UK NCSC CAF	* B2.a – Identity verification and authorisation
FedRAMP	* AC-2, AC-3, AC-6 (Moderate/High baseline)
CMMC 2.0	* AC.L2-3.1.5 – Employ the principle of least privilege
IT-Grundschutz	* ORP.4 – Identitäts- und Berechtigungsmanagement
IRAP	* ISM – Access control – Privileged access
CCCS PBMM	* AC-6 – Least privilege
MAS TRM	* Ch.6 – Access control
ISMAP	* Access control – Least privilege
FISC	* Technical measures – Authorisation management
EUCS (ENISA)	* IAM-01 – Identity and access management * IAM-03 – Least privilege access control

Framework

Controls

ISO 27001:2022

* A.8.2 – Privileged access rights * A.8.3 – Information access restriction * A.5.15 – Access control

ISO 27017

* CLD.9.5 – Segregation in virtual computing environments

CIS Controls v8

* CIS 5 – Account Management * CIS 6 – Access Control Management

SOC 2 Type II

* CC6.1 – Logical access security * CC6.3 – Authorisation and segregation of duties

NIST SP 800-53

* AC-2 – Account Management * AC-3 – Access Enforcement * AC-6 – Least Privilege

NIST CSF 2.0

* PR.AA-01 – Identities and credentials are managed * PR.AA-05 – Access permissions are managed

GDPR

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

PCI DSS v4.0

* Req 7 – Restrict access by business need to know * Req 7.2 – Access based on least privilege

CSA STAR

* CCM IAM-09 – User Access Authorization * CCM IAM-10 – User Access Reviews

BSI C5:2020

* IDM-01 – Identity and access management policy * IDM-03 – Access control and authorisation

TISAX

* Information security – Access rights management

ANSSI SecNumCloud

* Domain – Access management and least privilege

BIO

* BIO – Toegangsrechten en autorisatiebeheer

ENS High

* op.acc.4 – Proceso de gestión de derechos de acceso * op.acc.7 – Gestión de privilegios

UK NCSC CAF

* B2.a – Identity verification and authorisation

FedRAMP

* AC-2, AC-3, AC-6 (Moderate/High baseline)

CMMC 2.0

* AC.L2-3.1.5 – Employ the principle of least privilege

IT-Grundschutz

* ORP.4 – Identitäts- und Berechtigungsmanagement

IRAP

* ISM – Access control – Privileged access

CCCS PBMM

* AC-6 – Least privilege

MAS TRM

* Ch.6 – Access control

ISMAP

* Access control – Least privilege

FISC

* Technical measures – Authorisation management

EUCS (ENISA)

* IAM-01 – Identity and access management * IAM-03 – Least privilege access control