Data protection

Data labels let you define what must not leave through an agent: personal data, customer identifiers, project codenames, anything that would be a breach if it appeared in a prompt, a log or a tool call. AgentShield scans shell commands and MCP tool arguments for them before the action runs.

Three kinds of detector

Detector	Use it for	Notes
Regex with context	Structured values such as SSNs, card numbers, account ids	An optional context keyword (for example ssn near the number) removes most false positives. Patterns are compiled once at startup.
Keywords	Codenames, customer names, internal hostnames	Scanned in a single pass with an Aho-Corasick automaton: microseconds, however many keywords you add.
Validators	Values a regex matches too loosely	A Luhn check rejects random digit runs that look like card numbers. Validators are pluggable.

Defining a label

# policy.yaml
data_labels:
  - id: pii-ssn
    decision: BLOCK
    patterns:
      - regex: '\b\d{3}-\d{2}-\d{4}\b'
        context: "ssn|social.security"
  - id: project-codenames
    decision: AUDIT
    keywords: ["Project Kestrel", "kestrel-prod"]
    scope:
      tools: ["write_file", "http_request"]

Labels can be scoped to specific MCP tools or to direction (arguments going to a server, results coming back). When no labels are defined the layer costs nothing.

Where it runs

Data labels are the seventh analyzer layer, after the structural and dataflow layers, so a label can also catch a secret that was read from a file and is now on its way to the network. See the policy guide.

Plans

Custom data labels are an Enterprise feature. Every plan gets the built-in credential-path and secret-in-argument protections.