Security

Last updated: 2026-05-12

Chronary stores calendar data and API credentials on behalf of developers and the AI agents they build. This page describes the commitments we make to protect that data, how to report a vulnerability, and how we respond to incidents.

Encryption

Your data is encrypted in transit and at rest. Sensitive fields — including the credentials we use to access your external calendar feeds and the signing secrets we issue for your webhooks — receive an additional layer of encryption beyond storage-level so that a database snapshot alone is not sufficient to read them.

Account access

API keys are shown to you exactly once at the moment of creation; we store an irreversible one-way representation, never the key itself. Lost keys cannot be retrieved — only rotated. Console sessions expire automatically. Abusive clients are throttled at the network edge before they reach your data.

Webhooks

Every webhook payload Chronary delivers is cryptographically signed with a secret unique to that webhook, so your endpoint can verify the request actually came from Chronary and was not modified in transit. Delivery is asynchronous and retried on failure; your endpoint should be idempotent. Verification code is published in our developer documentation.

Per-organization isolation

Each organization's data is logically isolated. Customer accounts cannot read, list, or modify other organizations' calendars, events, agents, or webhook configurations through the Chronary API.

Monitoring

We continuously monitor service health and page our engineering team automatically when something looks wrong. Logs are redacted of common sensitive values before they reach our analytics pipeline; API keys, where they appear at all, are logged only as truncated prefixes.

Compromised credentials

If you suspect an API key has been exposed, rotate it immediately through the console and notify us at [email protected]. We may proactively revoke keys that we believe have been compromised and will notify the account owner when we do so.

Incident response

Security incidents are handled by the Chronary engineering team under a defined runbook:

1. Detect. Alerts come from monitoring, customer reports, or responsible disclosures.
2. Contain. Credentials can be revoked per-key, per-organization, or globally. Affected functionality can be disabled.
3. Investigate. Engineering identifies root cause and determines impact scope.
4. Notify. For personal-data breaches we will notify affected customers without undue delay and in any event within the timelines required by applicable law, including the 72-hour window under GDPR Article 33.
5. Remediate. The root cause is fixed, controls are strengthened, and a post-mortem is written.

Responsible disclosure

We welcome security researchers. If you believe you have found a vulnerability, please email [email protected] with a description and reproduction steps.

• Acknowledgment: we aim to acknowledge receipt within 72 hours.
• Triage and fix target: critical vulnerabilities within 30 days; others on a risk-prioritized schedule.
• Safe harbor. Good-faith research that (a) respects user privacy, (b) avoids data destruction or service disruption, (c) does not exfiltrate data beyond what is necessary to demonstrate the issue, and (d) gives Chronary reasonable time to remediate before public disclosure will not result in legal action from Chronary under the Computer Fraud and Abuse Act, DMCA Section 1201, or applicable anti-hacking laws.
• Out of scope: social engineering of Chronary staff or contractors, physical attacks, denial-of-service testing, and findings that require compromise of a third-party service.
• No bug bounty at launch. We may introduce a formal bounty program in the future.

Compliance

• GDPR and UK GDPR. Chronary processes personal data in accordance with our Privacy Policy.
• CCPA. We do not sell or share personal information as those terms are defined by the California Consumer Privacy Act.
• HIPAA. Chronary is not currently offered as a HIPAA-compliant service; calendar data processed through the API should not contain protected health information (PHI). Contact [email protected] if HIPAA support is a requirement for your use case.

Contact

For security matters, email [email protected]. For privacy questions, email [email protected].