Sensitivity and data classes
A data class is a label Kratex attaches to a sensitive target: a file, an environment variable, or a host. Built-in filename classification labels the common cases: credential stores like .aws/credentials, .npmrc, and .kube/config carry credentials; key material and env files like *.pem, id_rsa*, and .env* carry secrets; wallet files like wallet.dat and Ethereum keystore/UTC--* carry wallet. Some sensitive directories, ~/.gnupg among them, carry no class at all; they are covered by the literal credential-path rules instead. Classes let a rule talk about a kind of data rather than a specific path.
Built-in classification
From your sensitivity policy
Two conditions consume classes. targetClasses matches when the operation’s own target carries a class, so you can act on a kind of data wherever it lives:
{
"id": "my-app.audit-credential-reads",
"subject": { "source": "third-party" },
"target": { "kind": "fs", "operation": "read" },
"when": { "targetClasses": "credentials" },
"effect": { "action": "audit", "severity": "high" }
}
exposed matches an operation by a caller that previously touched a classed target during the run. Reading a credential stamps the caller with the credentials exposure, and a later outbound call matches exposed (this is the exfiltration shape the built-in outflow rules catch):
{
"id": "my-app.block-outflow-after-credential",
"subject": { "source": "third-party" },
"target": { "kind": "network" },
"when": { "exposed": "credentials" },
"effect": { "action": "block", "severity": "critical" }
}
.env is classed
credentials,
so a targetClasses rule matches the read.
The caller is now stamped exposed: credentials.
An outbound call from a caller carrying
exposed: credentials
matches a rule's exposed condition.
block the connection is refused
Use "exposed": "*" to match any exposure, whatever the class.
Declaring your own
Add patterns to the sensitivity block to classify paths, environment variables, or hosts beyond the built-ins:
{
"sensitivity": {
"paths": [
"secrets/**",
{ "pattern": "config/*.pem", "classes": ["credentials"] }
],
"env": [
{ "pattern": "STRIPE_*", "classes": ["secrets"] }
],
"hosts": [
{ "pattern": "*.internal", "classes": ["secrets"] }
]
}
}
Each entry is either a bare pattern, which carries the generic sensitive class, or { "pattern": …, "classes": [...] } to assign classes of your own naming. Your classes then work in targetClasses and exposed exactly like the built-in ones. The full schema is in the policy reference.