Data controls and deployment

Security begins before a trace reaches Neatlogs. Decide what the application may capture, which people and AI workflows may read it, how long it should remain, and where it may be processed.

This page distinguishes product controls from deployment or contractual requirements that must be confirmed for your organization.

Start with data minimization

Capture only what is required to understand and improve agent behavior.

• Prefer stable internal end-user IDs over email addresses.
• Exclude passwords, access tokens, authorization headers, and secrets.
• Avoid copying complete customer records into span attributes.
• Capture tool inputs and outputs only when they are needed for investigation.
• Review third-party provider data policies before sending trace evidence to AI evaluators.

Redaction is a safety layer, not permission to collect unnecessary data.

Configure PII controls before production

Neatlogs has two independent redaction controls, plus detections you can use to flag exposure:

Server-side redaction is not a reason to skip SDK masking. If data must not leave your infrastructure, mask it in the SDK first. The fail-closed guarantee covers normal asynchronous trace ingestion; other product endpoints have their own contracts. See PII redaction for the canonical behavior and SDK setup.

Set the project policy

The project policy lives under Settings → Project → PII redaction. Only project admins can change it (organization owners and admins are always project admins). Other members can inspect and test the policy; ask a project admin to save changes.

1. Select Enable PII redaction.
2. Under What to redact, choose built-in entity types (for example Email, Phone, Credit Card, or Person Name) or enter a Label and Regular expression and select Add pattern.
3. Under Where to apply, choose span types. No selection means every span type.
4. Under How to transform, choose Replace, Mask, or Remove.
5. Select Save policy.

Use the Playground tab to paste Sample text and review the Redacted output before saving.

Test the policy on representative non-production traces. Confirm what remains visible in inputs, outputs, tool data, attributes, search, and downstream AI workflows.

Understand redaction limits

• A new policy does not automatically clean historical data.
• Redaction may remove evidence needed for an Eval or investigation.
• Pattern-based controls can miss unrecognized sensitive content.
• Imported traces may already contain values captured by the source.
• Managed prompt content is a separate data path; telemetry masking does not rewrite it.
• External tickets, Slack messages, and exports follow their own data controls.

When required evidence is redacted, the reviewer or investigation should report insufficient evidence rather than infer the missing value.

Plan retention and deletion

The dashboard does not expose a retention setting. Confirm with Neatlogs:

• default retention period;
• whether projects can use different periods;
• archive and backup behavior;
• deletion workflow;
• treatment of imported history;
• historical cleanup after a policy change;
• deletion behavior for external exports and connected systems.

Organization owners and admins can archive a project (it can be restored later) or delete it from the workspace switcher. A deleted project becomes unavailable, and any retained data follows the applicable retention policy.

Verify data residency and AI processing

Neatlogs runs separate US and EU deployments:

Projects, keys, and tokens belong to the deployment that issued them and do not work in the other region. Point SDKs at the ingest endpoint for your project's region.

Residency covers more than the region of an import source.

Ask where:

• primary telemetry is stored;
• backups and archives reside;
• AI investigation and evaluation processing occurs;
• model providers process evidence;
• support access is performed;
• logs and derived data are retained.

AI features use the Neatlogs-managed model unless a project uses its own provider key, in which case that provider processes the evidence. Verify these requirements against the deployment documentation or agreement. Do not infer them from a provider endpoint alone.

AI evaluators have one more control. The Decision model setting sends trace input and output, evidence, and grading criteria to the external provider TypeSafe for extra processing beyond the selected model. For a user without a saved preference, new evaluators default to on; the editor remembers the user's preference. Check it on each evaluator and turn it off when evidence must stay with the selected model.

Control access and connected systems

Use project access for telemetry boundaries and grant external tools only to the workflows that need them.

Review:

• organization and project membership;
• guest review scope;
• service accounts and their project bindings;
• Slack, Discord, GitHub, Linear, and Jira connections;
• personal Tools & MCP connections;
• AI evaluator evidence and tool grants;
• model-provider credentials;
• project API keys and HTTP ingest keys.

Removing a Neatlogs permission may not revoke data already exported to an external system.

Understand activity and audit evidence

Settings → Organization → Activity is visible to organization owners and admins. It currently records project archive, restore, and deletion only. Entity change history, alert history, import jobs, and incident lifecycle events provide other operational provenance.

Do not represent these records as a comprehensive compliance audit log.

Confirm enterprise and deployment requirements

The dashboard supports email and password or Google sign-in and has no SAML SSO or SCIM settings. Capabilities such as SSO, provisioning, private networking, and self-managed deployment are not self-service; the Public API and CLI do not support self-hosted deployments.

Before relying on one, confirm with Neatlogs:

• supported configuration;
• identity and provisioning ownership;
• upgrade and incident responsibilities;
• backup and recovery process;
• observability and support boundaries;
• security documentation and contractual commitments.

Infrastructure present in a codebase is not itself a public support commitment.

Security review checklist

Before production:

1. define allowed and prohibited trace data;
2. test SDK masking and the project's PII redaction policy;
3. set project membership and reviewer scope;
4. inspect integration and AI-tool permissions;
5. confirm retention, deletion, residency, and model processing;
6. store keys through approved secret paths;
7. document how to report a suspected exposure;
8. verify the controls again after major workflow changes.

Frequently asked questions

Is data encrypted?

Exact encryption, key management, and compliance commitments must come from Neatlogs security documentation or your agreement. Saved credentials such as provider keys and secrets are write-only in the dashboard and cannot be revealed after saving.

Can I choose retention in the dashboard?

No. Confirm retention with Neatlogs.

Does redaction remove previously stored values?

No. Enabling a policy does not retroactively clean historical data by itself.

What happens if server-side redaction fails?

On normal asynchronous trace ingestion, the event is retried rather than stored unredacted. Other endpoints have their own behavior, so mask data in the SDK when it must never leave your process.

Is self-managed deployment available?

Confirm supported deployment options and responsibilities directly with Neatlogs.

What should I do if a secret appears in a trace?

Revoke the secret at its provider, restrict access to the affected evidence, and follow the organization's incident and deletion process.

Next step

Review troubleshooting and support →