Redaction and sensitive fields

Kumo.io stores the configuration of your cloud resources and how they connect, never the data inside them. Fields that are sensitive by nature are flagged when Kumo.io reads them, cloud credentials are kept encrypted, and secret values are hidden wherever Kumo.io shows or sends changes.

Applies to: BothPlan: Allconfiguration, not contentscredentials encrypted at restyour own redaction rules

What Kumo.io reads How sensitive fields are classified Your own redaction rules Credentials are kept encrypted Where Kumo.io hides values on the way out Self-hosted: changing classifications

What Kumo.io reads

Kumo.io reads your cloud through read-only access and records configuration: which resources exist, their settings, and how they connect to each other. It doesn't read the data stored in your resources, such as the objects in a bucket or the rows in a database.

Some configuration is sensitive in its own right, and Kumo.io's readers leave the most sensitive values out. Two AWS examples:

Secrets Manager: Kumo.io lists your secrets and their settings, but never calls the API that returns a secret's value.
Lambda environment variables: Kumo.io notes that a function has environment variables and flags them as sensitive, but doesn't record their values.

How sensitive fields are classified

Each cloud provider Kumo.io supports comes with a definition that names the fields that are sensitive by nature. A field is matched either by an exact rule for one resource type, or by a name pattern, such as password, privatekey, secretaccesskey, sessiontoken or policydocument. Matching ignores case and punctuation, so assumeRolePolicyDocument and assume_role_policy_document match the same rule.

Each match gives the field one of these classifications:

Classification	For example
`secret`	Passwords, private keys, instance user data, function environment variables
`credential`	Access key IDs and secret access keys, session tokens, API keys
`security_policy`	IAM, key and bucket policy documents
`network_exposure`	Public IP addresses, CIDR ranges
`sensitive_metadata`	PEM-encoded certificates
`personal_data`, `internal_metadata`, `public_metadata`	Other kinds of field

Kumo.io flags each sensitive field it finds as it reads your cloud.

Your own redaction rules

You can tell Kumo.io to redact or drop specific fields before they are stored, with sensitive-field policies. Policies are set per account through the API:

POST /v1/accounts/{accountId}/sensitive-field-policies
{
  "name": "Hide instance tags",
  "attributePathGlobs": ["tags.*"],
  "action": "redact"
}

attributePathGlobs lists field paths: an exact path, or a path ending in .* for everything under it.
action is redact (the value is replaced with [REDACTED]), omit (the field is dropped) or pseudonymize (the value is replaced with a placeholder).
Policies apply to everything Kumo.io stores from the next sync on. Revisions that were already sealed are never edited, so they keep what they recorded.
Creating or deleting a policy needs the policy.write permission, which the account owner, admin and editor roles have.

The name and path in the example are illustrative. GET on the same path lists your policies, and DELETE /v1/accounts/{accountId}/sensitive-field-policies/{policyId} removes one.

A production installation refuses to start if it isn't applying these policies, or if it can't store secrets encrypted.

Credentials are kept encrypted

When you paste a cloud credential into Kumo.io, the secret is written encrypted, and the credential record keeps only a reference to it. Kumo.io decrypts the secret only when a sync or connection test needs it. On a self-hosted installation you can instead point Kumo.io at a secret you keep elsewhere, such as an environment variable or a 1Password item, so the secret never enters Kumo.io's database. See Credentials.

Where Kumo.io hides values on the way out

Where	What Kumo.io does
Change comparisons	When a changed field's name suggests secret material (password, secret, private key, access key, connection string, token, refresh token, API key, kubeconfig or certificate), both values are replaced with a redacted marker before the comparison is stored. The change itself is still reported, as Sensitive field changed at `high` severity. See Changes and diffs.
Cost	Actual and allocated amounts need permission to read cost actuals, and raw billing evidence needs permission to read cost evidence. Negotiated contract rates are always hidden without it. Estimates stay visible.
Notifications	Each notification is checked and redacted for each recipient before it is sent, so an email or Slack message never carries something its reader couldn't see in Kumo.io.
Reports	A report states its redaction mode and how many fields were redacted. Exporting a report can only hide more, never less.
Support bundles	`kumo support bundle` builds a redacted diagnostics bundle for sending to support. See Support bundles.

Self-hosted: changing classifications

On a self-hosted installation, an administrator can layer overrides onto a provider definition with kumo provider-definition-override set, for the whole account or for one workspace. Overrides can only make a sensitive field stricter. A field classified as secret or credential can't be moved to a weaker classification, and its storage and indexing rules can only be strengthened. An override that tries is not applied.