Trust

Security

Last reviewed: 17 May 2026

EZLogs reads activity from your application and shows it back to your team. It never writes back into your stack. Everything below is built around that principle.

Read-only by design

This is the foundation, not a feature. EZLogs holds no write credentials into your application: no webhooks emitted into your stack, no “pause agent” toggle that throttles your code, no MCP tools that perform actions, no approval queues that send anything anywhere. The blast radius of an EZLogs compromise is fundamentally read-only — an attacker who took over our service could see your event data but could not act on your behalf inside your application.

This is committed in our product invariants and applies permanently to v1 and v1.x.

Where data lives

• Hosting: Hetzner Online GmbH, Germany. EU jurisdiction throughout.
• Database: PostgreSQL on the same dedicated server, encrypted at rest at the filesystem layer.
• Backups: daily, encrypted, retained for 14 days, stored in the same EU jurisdiction.
• Transit: TLS 1.2+ on every connection. We do not accept plaintext HTTP for ingestion.

Redaction by default

The EZLogs agent applies field-level redaction before events leave your application. Any column, parameter, or header whose name matches one of these patterns is replaced with [redacted] at the source:

• password, password_*, *_password
• token, *_token, token_*
• secret, *_secret
• key, *_key, api_key, private_key
• *_at timestamps that look like internal-only data

You can extend the redaction list with your own patterns in the agent configuration. We never store request bodies, response bodies, or full database rows unless you explicitly opt in at the agent layer.

Public surfaces — one redaction layer

Any data that leaves the EZLogs app — via the MCP server, a public share URL, an embedded widget, or an audit export — passes through a single redaction pass before it ships. Shared and embedded artifacts default to a conservative allowlist (display-name fields only); full visibility requires explicit per-share opt-in. The MCP server and audit exports default to your full data, because they are your AI and your admin reading your data — redaction would be incorrect there.

Access controls

• Authentication: bcrypt-hashed passwords, brute-force protection (Rack::Attack), session-based auth with secure cookies.
• Multi-tenant isolation: all customer data is scoped by company_id at the database query layer; cross-tenant access is impossible by construction.
• User scoping: some data is per-user, not per-tenant. Chat threads and messages, for example, are not visible to other users in the same company — even to admins.
• Operational access: only the founder has production database access. All access is via SSH key (no passwords), from named machines.

The agent is built to be safe

• Out-of-band: events are buffered in memory and shipped over a separate connection. Your customer’s request never waits on us.
• Fails open: if EZLogs is unreachable, the agent buffers up to 10,000 events and retries with exponential backoff. If the buffer overflows, the oldest events are dropped. The agent never raises into your request path.
• Low overhead: measured average overhead under 1 ms per request in benchmarks.
• Open source: the agents (ez_logs_agent, ezlogs-nextjs) are open-source and auditable. You can pin to a known SHA.

AI and your data

When EZLogs renders a plain-English explanation of an action, the already-redacted structured event data is sent to a large-language-model provider (currently Anthropic and/or OpenAI — toggleable per-deployment). Both providers contractually commit not to train on inference inputs. Explanations are cached and reused, so the same event is not sent to a model twice. You can disable AI explanations per tenant if you require it.

The AI never invents facts. Pulse state values shown in the product are deterministic folds of the action stream — every value is traceable to specific events; AI is only used to phrase explanations using data your app actually sent.

Vulnerability disclosure

If you find a security issue, please email security@ezlogs.io with a description and reproduction steps. We respond within 72 hours, work in good faith on a fix, and credit you publicly once the issue is resolved (unless you prefer to remain anonymous). Please do not publicly disclose until we have had reasonable time to fix.

What we do not (yet) have

EZLogs is a small, early-stage product. To set honest expectations, we do not currently hold SOC 2, ISO 27001, or HIPAA certifications. We do not offer self-hosting (on the post-launch roadmap). If a formal certification is a hard procurement requirement, contact hello@ezlogs.io and we will talk honestly about timing.

Related

• Privacy Policy — what data we collect and your rights over it.
• Subprocessors — the third parties we use to operate the service.
• Data Processing Agreement — for GDPR-compliant B2B contracts.