Sensitive fields are values that should not be stored, indexed, or exposed in telemetry.
Foveus applies redaction and backend safety controls, but your team should still decide which fields are safe to capture for your services.
Do not intentionally send secrets, credentials, card data, authentication tokens, or highly sensitive personal data to Foveus.
Common sensitive fields
Foveus redacts many common sensitive keys by default.
Examples include:
password
passcode
pin
otp
token
accessToken
refreshToken
authorization
cookie
secret
apiKey
cardNumber
cvv
cvc
The exact default list may change as Foveus improves its safety controls.
Add your own sensitive fields
Every product has domain-specific fields that may be sensitive.
Add them to RedactedFields.
{
"Foveus": {
"ApiKey": "fov_test_...",
"RedactedFields": ["nationalId", "accountNumber", "dateOfBirth"]
}
}
Redaction changes apply to newly captured telemetry.
If your service uses custom headers for authentication, session state, internal tokens, or provider credentials, add them to RedactedHeaders.
{
"Foveus": {
"ApiKey": "fov_test_...",
"RedactedHeaders": ["x-internal-token", "x-session-secret"]
}
}
What to avoid capturing
Avoid capturing values such as:
- passwords
- one-time passcodes
- PINs
- session tokens
- access tokens
- refresh tokens
- API keys
- authorization headers
- cookies
- card numbers
- CVV or CVC values
- private keys
- secrets
- full identity documents
- highly sensitive personal data
If your service handles these values, use redaction and path exclusions.
Safer values to search by
Execution Context Search is most useful when you search by stable, non-secret identifiers.
Good examples:
customerId
userId
orderId
transactionId
requestId
reference
providerReference
correlationId
These values can help you find executions without exposing secrets.
For example:
service:orders-api context:customerId="cus_12345"
or:
service:orders-api context:request_id="req_12345"
Redacted fields are not searchable
If a field is redacted, Foveus does not index the original value for search.
For example:
{
"Foveus": {
"ApiKey": "fov_test_...",
"RedactedFields": ["accountNumber"]
}
}
If your response contains:
{
"accountNumber": "1234567890"
}
Foveus should store a masked value instead of the original value.
Do not expect this search to work:
service:orders-api context:accountNumber="1234567890"
Use a safer identifier instead:
service:orders-api context:customerId="cus_12345"
Sensitive routes
Some routes are more likely to contain sensitive data.
Examples:
/auth
/login
/register
/password
/token
/payment-methods
/profile
Use path exclusions when needed.
{
"Foveus": {
"ApiKey": "fov_live_...",
"Mode": "live",
"ExcludedPathPrefixes": ["/auth", "/health", "/metrics"]
}
}
You can also exclude exact paths.
{
"Foveus": {
"ApiKey": "fov_live_...",
"Mode": "live",
"ExcludedExactPaths": ["/auth/login", "/auth/refresh"]
}
}
Response context
Response context is useful when you need to see what your service or a provider returned.
For example:
{
"orderStatus": {
"value": 1,
"label": "Confirmed"
}
}
This can be safe and useful to search:
service:orders-api context:orderStatus.value=1
But response bodies can also include sensitive values.
Before enabling response capture broadly, review the fields your APIs return and add redaction rules.
{
"Foveus": {
"ApiKey": "fov_live_...",
"Mode": "live",
"CaptureResponseBodies": true,
"RedactedFields": ["nationalId", "accountNumber", "dateOfBirth"]
}
}
Request context
Request context helps you understand what a client sent.
For example:
{
"customerId": "cus_12345",
"orderId": "ord_12345"
}
This can be useful for investigation.
But request bodies can also include credentials, account details, or personal data.
For sensitive routes, use path exclusions or disable body capture.
{
"Foveus": {
"ApiKey": "fov_live_...",
"Mode": "live",
"ExcludedPathPrefixes": ["/auth"],
"RedactedFields": ["password", "otp", "token"]
}
}
Searchable context safety
Foveus applies backend safety controls before indexing context.
These controls can include:
- sensitive-key denylist
- redaction
- scalar-only indexing
- bounded value length
- bounded key length
- maximum traversal depth
- maximum indexed properties per execution
- workspace and service policies
Sensitive fields should not become searchable context.
Recommended production checklist
Before sending live telemetry:
- Review request and response fields for sensitive data.
- Add domain-specific fields to
RedactedFields.
- Add custom sensitive headers to
RedactedHeaders.
- Exclude sensitive routes.
- Keep response capture enabled only where useful and safe.
- Use sampling for high-volume services.
- Trigger test requests in Test mode.
- Open executions and confirm redaction works.
- Search by safe identifiers, not secrets.
Example production setup
{
"Foveus": {
"ApiKey": "fov_live_...",
"Mode": "live",
"CaptureProfile": "Balanced",
"CaptureRequestBodies": true,
"CaptureResponseBodies": true,
"ContextSamplingRate": 0.01,
"ExcludedPathPrefixes": ["/auth", "/health", "/metrics"],
"RedactedFields": ["nationalId", "accountNumber", "dateOfBirth"],
"RedactedHeaders": ["x-internal-token"]
}
}
Troubleshooting
A sensitive field appears in Foveus
Add the field to RedactedFields.
{
"Foveus": {
"ApiKey": "fov_test_...",
"RedactedFields": ["sessionCredential"]
}
}
Then trigger a new request.
Redaction applies to newly captured telemetry.
Add the header to RedactedHeaders.
{
"Foveus": {
"ApiKey": "fov_test_...",
"RedactedHeaders": ["x-session-secret"]
}
}
Context search finds a field it should not
Add the field to redaction or policy controls, then trigger new telemetry.
Existing retained data may still reflect the old settings until it expires or is removed.
Context search cannot find a field
Check whether the field was redacted, denied by policy, excluded by route, skipped by sampling, or outside retention.
What to do next