How to Check If Your AI Website Is Hacked

Compromised AI-built apps often show different indicators than traditional hacked websites. There may be no defacement, no obvious downtime, and no error messages. Instead, the attacker is quietly reading user data, running up your API bill, or establishing persistence for a future attack. Knowing what to look for — and where to look — is the difference between catching a breach early and discovering it months later in a much larger incident.

How AI App Compromises Typically Start

In PolyDefender's incident analysis, three entry points account for the majority of compromised AI-built apps: an exposed API key scraped from a public repository or JavaScript bundle, a missing server-side ownership check that allows cross-tenant data access, and a dependency with a malicious install script introduced during an AI-assisted refactor.

Unlike traditional SQL injection or XSS attacks that cause visible errors, these entry points allow quiet, low-noise access. An attacker with your Supabase service_role key can enumerate your entire database with legitimate-looking queries. An IDOR vulnerability allows reading any user's data with normal authenticated requests. Neither leaves obvious traces.

Billing and Usage Anomalies

The fastest signal of compromise is unexpected spending. AI API costs and cloud costs that exceed your normal patterns by 2x or more within a day should be treated as a potential incident until proven otherwise.

• ▸Check your OpenAI usage dashboard for model calls you did not initiate — particularly large context or image generation requests
• ▸Check Stripe for webhook registrations, payout destination changes, or charge reversals you did not authorize
• ▸Check your hosting provider (Vercel, Railway, Render) for unusual bandwidth, function invocation spikes, or new environment variables
• ▸Check Supabase for database egress volume, unusually large SELECT queries, or bulk INSERT/DELETE operations

Authentication and Access Anomalies

Review your authentication logs for patterns that do not match your user base's normal behavior.

• ▸New admin user accounts or role escalations you did not perform
• ▸Authentication events from unexpected geographic locations for existing users
• ▸A single account making a very large number of API requests in a short period
• ▸Password reset requests for accounts that were not initiated by the account holder
• ▸New API keys or tokens created in any of your third-party service dashboards

Checking for Outbound Exfiltration

Sophisticated attacks exfiltrate data silently through outbound HTTP requests that look like normal telemetry. Check your server logs for requests to domains that are not in your known third-party list.

In Vercel: Functions → Logs → filter for outgoing fetch calls. In Supabase: Logs → Edge Functions. In your application logs: grep for fetch, axios, or http.request calls to non-whitelisted domains. Anything calling an IP address directly (rather than a domain name) is a strong indicator of malicious activity.

If You Find Evidence of Compromise

• ▸Immediately rotate all privileged credentials in order of blast radius: service_role keys first, then third-party API keys, then application secrets
• ▸Freeze all deployments until the root cause is identified — prevent the attacker from pushing changes or reestablishing persistence
• ▸Capture your logs before they roll over: download Vercel function logs, Supabase logs, and any application logging service exports
• ▸Check git history for unauthorized commits, branch creations, or changes to environment variable configuration
• ▸Notify affected users if you have reason to believe their data was accessed — this is both ethically correct and legally required in many jurisdictions

Hardening After an Incident

Once containment is complete, the priority shifts to ensuring the same entry point cannot be used again. Run a full PolyDefender scan on your post-incident deployment to verify no additional vulnerabilities were introduced during the compromise. Add deploy-time scanning to your pipeline so that future credential exposures or authorization regressions are caught before they reach production. Review every third-party integration for least-privilege: each service should only have the permissions it needs, nothing more.