TAISC has been approved for OpenAI Daybreak

Since late October, TAISC has been approved for OpenAI Daybreak Blue. Daybreak is OpenAI’s cyber program for verified defenders. It gives us access to the cyber capabilities of OpenAI’s models, with far fewer refusals when it comes to security-critical analysis.

The timing could hardly have been better. In the week around October 21 came emergency patches for two critical PHP vulnerabilities found with AI, a supply-chain attack on the LLM gateway LiteLLM and a security incident at the hosting provider Railway. What this means for companies running AI agents, n8n workflows and AI-built apps is covered in AI security in the enterprise.

Why this matters to us

• Every application we build for clients goes through an AI-assisted security review before go-live. An agent reads the code in context, traces data flows and permissions and finds logic flaws that a pattern scan misses.
• With Daybreak Blue we can go deeper without constantly running into safety filters, for example when we check how a vulnerability we found could be exploited.
• Attackers use the same models. On the defender side, we want to be at least as well equipped.

What we check in a security review

A security check with us is not just a scanner run. We combine automated tools with an AI review and verify every finding by hand:

• Roles and permissions: who may see and change which data? For Supabase apps this mainly means row level security on every table, tested with real user roles.
• Secrets: API keys and passwords in the code or the version history, and whether keys can be rotated quickly in an emergency.
• Dependencies: known vulnerabilities and suspicious packages in the software supply chain.
• APIs and webhooks: authentication, input validation and what happens when someone calls the interface directly.
• AI features: prompt injection, data leaking through assistants and overly broad permissions for agents.
• Operations: deployment, backups, monitoring and an incident plan for who does what.

We prioritize findings by risk and fix them directly on request. Two examples: the security check of a self-built intranet and the security audit of a Lovable app, where we found and closed two critical vulnerabilities before go-live.

Security from the first line of code

Model access alone does not make an application secure. For us, two-factor sign-in everywhere, hardware keys for critical accounts and minimal permissions for every interface and every agent are standard. We host our applications in the EU, in Germany where possible, and build in data protection from the start, for example in Baukraft360, which passed Apple’s and Google’s reviews.

Apps that companies build themselves with Lovable, Cursor or Claude Code in particular deserve a second look before go-live. How that works is described in Taking vibe coding to production. How we work together is described under Services.