Security overview

What we do to keep your credentials and content safe, stated plainly.

Transport

• TLS on every endpoint. There is no plaintext HTTP entry point.
• HSTS with preload on all web properties.
• Strict security headers: no sniffing, framing restricted, referrer trimmed.

Access control

• Customer keys are scoped to a single account and cannot read anyone else's data.
• Administrative access is guarded by a single secret compared in constant time.
• Inference providers are reached only from the server side; their credentials never reach a browser.
• Failed authentication attempts are rate limited.

Isolation and quota

Quota counters are strongly consistent per account, so one customer's traffic can never consume another's budget. Capacity has guaranteed floors per plan, so a large tenant cannot starve smaller ones completely.

Data retention

Reporting a vulnerability

If you believe you have found a security issue, contact us through the support page with the subject Security report. Please include:

• A description of the issue and its impact.
• Steps to reproduce, ideally minimal.
• Whether any real customer data was accessed.

We acknowledge reports within 3 business days and will keep you updated until resolution. Please do not run automated scanners or load tests against production without written permission, and do not access data that is not yours.

You can also reach the security contact directly at dwia20353@gmail.com or via Telegram @AunuHostv — use the subject Security report. Good-faith research that follows the rules above, and that reports findings to us before any disclosure, is welcome; we will not pursue claims against researchers who stay within them.

Security programme

Security work is continuous rather than a one-off project: the platform’s public changelog records hardening releases, and this page is updated when a practice changes materially. This overview is deliberately plain-language — it describes what we do, and it is not a certification or an audit report.

Encryption and key material

• All traffic is encrypted in transit with TLS; there are no plaintext endpoints (see Transport).
• Customer API keys exist in our data stores only as salted hashes — a database disclosure alone does not expose a usable key.
• Provider credentials used by the gateway are held server-side as protected secrets; they are never shipped to browsers, embedded in client code, or written to logs.
• Administrative access to the platform uses a single secret compared in constant time, with failed attempts rate-limited and lockouts applied.

Identity and sessions

• Dashboard sign-in is Google-only (Google OAuth 2.0): we never receive or store your Google password, and one Google identity maps to exactly one account. See the Privacy Policy, Section 3.
• Session tokens are delivered to the browser only through the URL fragment after sign-in, so they are not sent to servers in request URLs or written into access logs.
• You can revoke AunuCore’s access at any time from your Google account’s third-party access page, and rotate or revoke your API key at any time from your dashboard.

Edge protection

• An anti-DDoS guard plane (proof-of-work gate, per-IP and per-device rate limiting, automated-client blocking) sits in front of the application.
• Well Defend Mode: when a request flood is detected, the platform seals itself — direct API traffic is turned away, legitimate traffic continues through separate shield edges, and the site restores itself automatically when the flood subsides. Live mode is visible at GET /api/defend/status.
• Abuse controls include rate limits on authentication, quota isolation per account, and an audit log of privileged actions.

Vulnerability management

• Dependencies and edge components are updated as security fixes are released; platform changes ship through the public changelog.
• External reports are triaged by impact. We acknowledge within 3 business days (see Reporting a vulnerability).
• Findings that affect customer data are prioritised above feature work until resolved.

Incident response

• On a confirmed incident we contain first, then investigate scope using security and audit logs (retained 90 days).
• If a breach affects your data we notify affected accounts and, where required, regulators without undue delay, as committed in the Privacy Policy.
• Material platform events are announced on the status page.

Your responsibilities

• Keep keys server-side and rotate them if exposure is suspected.
• Add authentication to any route of yours that forwards to AunuCore.
• Set max_tokens to bound cost and output size.

See the key security guide for a practical checklist, and our Privacy Policy for data handling detail.

Agent and bot deployments

If your API key powers an automated agent or bot on Telegram, Discord, WhatsApp or a similar platform, the requirements below apply in addition to everything above. They are the security counterpart of Section 20 of the Terms and Section 18 of the Privacy Policy.

Key storage and handling

• Store keys in a secrets manager or in server-side environment variables. Never hardcode a key in source code, and never commit one to a repository — public or private.
• Use a separate key for each agent and each environment (development, staging, production), so a single leak can be revoked without taking every bot down. Named secondary keys exist for exactly this (see the key security guide).
• Rotate keys on a regular schedule — we recommend at least every 90 days — and immediately when a team member with access leaves, a device is lost, or exposure is merely suspected.
• Apply least privilege: run each agent on the lowest plan whose limits are sufficient, and do not share one key across unrelated projects or clients.
• Never ship a key inside a mobile app, desktop client, browser bundle or any other artefact your end users can download or inspect.

Update channels: webhooks and polling

• Verify that incoming updates really come from the platform before acting on them: check the secret token on Telegram webhooks, and verify Discord interaction signatures (Ed25519) on every request. An unverified webhook endpoint lets anyone on the internet drive your agent — and spend your quota.
• Serve webhooks over TLS only, and keep the webhook path unguessable where the platform allows it.
• Do not expose an agent’s admin panel, pairing screen or control dashboard to the public internet without authentication of its own. Our key authenticates your agent to us; it does not protect your panel.
• If you poll instead of using webhooks, protect the polling host to the same standard: it holds both your platform credentials and your AunuCore key.

Linked-device WhatsApp sessions

• A linked-device session is not a bot token: the stored session credentials give full access to the WhatsApp account, including reading and sending messages as that number. Protect session files like production secrets — encrypted at rest, restrictive file permissions, never in a repository or a shared archive.
• Anyone who copies the session folder can take over the number without the phone. If a session may have leaked, unlink the device from the phone’s linked-devices screen immediately and pair again from a trusted device.
• Unofficial linked-device clients can be detected by WhatsApp, and numbers used with them are banned without warning. That risk sits with the operator (Terms, Section 20); we cannot unban a number and cannot recover a lost session.
• Where possible, run the bot on a dedicated number rather than a personal one, so a ban or a session leak does not take your personal account with it.

Monitoring and leaked keys

• Watch your usage dashboard for anomalies — traffic spikes, models or endpoints your agent never calls, activity at hours your agent should be idle. Anomalies are usually the first sign of a leaked key.
• If a key leaks: revoke or rotate it immediately from your dashboard, then contact us at dwia20353@gmail.com or via Telegram @AunuHostv so we can check for abuse on the old key. Rotation invalidates the previous key at once.
• Rate limits, quota isolation and — during a flood — Well Defend Mode (see Edge protection) can engage automatically. Design your agent to back off and queue rather than retry in a tight loop, so legitimate traffic is not mistaken for an attack.

Reporting

• Security issues in your agent deployment that touch the platform — for example a key leak with signs of abuse — should be reported through the same channel as any other vulnerability: the support page with the subject Security report, or directly to dwia20353@gmail.com (see Reporting a vulnerability above). We acknowledge reports within 3 business days.