Security Is an Architecture Problem in the Age of AI
Security is often approached as a collection of tools. Put a firewall in front of the server, add a vulnerability scanner, rotate credentials, and run a penetration test. All of these controls matter, but as systems become more complex, security increasingly becomes an architecture problem.
There is another change happening at the same time: AI is accelerating security research on both sides of the equation. Ethical hackers can use AI to understand unfamiliar systems faster, discover attack paths, generate test cases and automate parts of vulnerability research, while criminal attackers can use the same capabilities to scale reconnaissance, credential attacks, social engineering and exploitation.
This changes the economics of security. An attack that previously required significant time and specialist knowledge can increasingly be explored with AI-assisted tooling, while defenders are still expected to secure increasingly complex applications, APIs, cloud infrastructure and AI agents.
The answer cannot simply be to add more security tools. We need to reduce the number of things that can be attacked, limit what each component can access, and design systems so that the compromise of one layer does not automatically compromise everything else.
That is the principle behind how we are evolving the security architecture of our AI-native platforms.
Reduce the attack surface
The simplest security improvement is often to remove things that do not need to be exposed. Every public service, open port, persistent credential and privileged integration creates another opportunity for something to go wrong.
This is particularly important for early-stage technology companies. Self-hosting infrastructure can be fast and inexpensive, but every service we operate becomes another system that has to be patched, monitored, secured and eventually penetration tested.
AI makes this even more relevant because attackers can increasingly automate reconnaissance and investigate multiple potential attack surfaces in parallel. Our approach is therefore increasingly simple: operate fewer exposed systems and make the systems we do operate easier to secure.
Security starts at the edge
For internet-facing applications, the first layer is the network perimeter. We use Cloudflare as an edge security layer, with host-level controls such as UFW providing another boundary around the underlying infrastructure.
The important point is that these controls solve different problems. Cloudflare can protect the public edge, while the host firewall limits what can reach the underlying machine.
No individual layer should be considered sufficient on its own. If one control fails, another should still limit the attacker’s options.
Secrets should not live beside the application
Development environments often begin with configuration files and .env variables. They are convenient, but production systems eventually accumulate database credentials, API keys, signing keys, cloud credentials and other secrets that should not be copied across machines and environments.
We are moving toward dedicated secret-management systems such as Infisical, where secrets can be centrally controlled, rotated and injected into applications when required. This separates the application from the long-lived credentials it needs to operate.
The objective is not simply to protect an .env file. It is to make production applications less dependent on plaintext secret files in the first place.
Simplifying CI/CD
CI/CD is one of the most privileged parts of modern infrastructure. A deployment system can potentially access source code, build artifacts, cloud infrastructure, environments and production credentials.
That makes the CI/CD layer part of the security boundary. The fewer systems we need to expose and maintain ourselves, the fewer systems we need to defend.
Where managed services provide the capabilities we need, we prefer them over maintaining additional internet-facing infrastructure. For example, managed CI/CD through GitHub Actions can reduce the operational and security burden of running another independently exposed deployment system.
The objective is not that a particular CI/CD product is inherently secure. The objective is to remove unnecessary infrastructure and reduce the number of systems that require privileged access.
Zero Trust inside the environment
Perimeter security is only one part of the problem. Once an attacker gains access to one application or service, unrestricted internal connectivity can turn a limited compromise into a much larger incident.
This is why we increasingly think in terms of Zero Trust. Being inside a network should not automatically mean being trusted.
A service should receive only the permissions it requires, a developer should receive only the environments they need, and a deployment workflow should not automatically receive unrestricted access to the cloud.
The principle is straightforward:
Every permission should have a reason, and every trust relationship should have a boundary.
AI introduces a new security boundary
AI-native applications introduce another dimension to application security. An AI system may process user input, documents, emails, websites and information retrieved from external systems, and not all of that information should be trusted.
Prompt injection is an example of this problem. Content retrieved by an AI system may contain instructions designed to influence the model into taking an unintended action.
There is an important symmetry here. AI can make attackers faster, but it can also make defenders faster. The difference is whether the underlying architecture gives either side too much leverage.
We therefore treat external content as untrusted input and separate instructions, retrieved information, tool outputs and system permissions. The model can reason about what should happen, but authorization should remain outside the model.
This distinction becomes increasingly important as AI systems move from answering questions to executing workflows. An agent should not be able to grant itself additional permissions simply because a prompt tells it to do so.
Minimize credential blast radius
Credentials are another important part of the architecture. A long-lived token with broad access may be convenient, but if that token is compromised, the resulting blast radius can be much larger than necessary.
We are therefore moving away from broad, long-lived Personal Access Tokens wherever possible. Fine-grained credentials, short-lived credentials, workload identities and repository-specific permissions provide much tighter boundaries.
The question should not be whether a credential has enough access. The better question is whether it has only the access required for that particular operation.
This matters even more in an environment where AI-assisted attackers can rapidly identify credentials and investigate what those credentials can access. A credential should therefore be treated as a potential failure point, not as a permanent trusted identity.
Security testing has to become continuous
Security cannot be a one-time exercise because the system itself is never static. New APIs are introduced, dependencies change, infrastructure evolves and AI agents acquire new capabilities.
The speed of AI-assisted security research makes this even more important. Ethical hackers can increasingly move from reconnaissance to hypothesis generation, testing and reporting much faster than traditional manual approaches, while criminal groups can use automation to probe large numbers of systems.
Our security approach therefore combines automated controls with recurring independent testing. This includes vulnerability scanning, secret detection, dependency analysis, application and API penetration testing, infrastructure testing and AI/LLM security testing.
External security researchers provide another important perspective. Someone looking at a system from outside the development team can often discover assumptions that the people building the system have become accustomed to.
Responsible disclosure matters
We believe ethical hackers and bug bounty hunters should be part of the security ecosystem. Finding a vulnerability before it becomes a larger incident is valuable to everyone involved.
The security industry is changing because AI lowers the barrier to sophisticated research. That means organizations need better channels for researchers to report vulnerabilities, understand severity and receive appropriate recognition for meaningful findings.
A responsible disclosure program can therefore become an additional security layer. It effectively turns a large community of independent researchers into an extension of the organization’s security testing capability.
Security is ultimately about containment
No architecture can guarantee that nothing will ever go wrong. Applications will contain vulnerabilities, credentials will occasionally be exposed, dependencies will have weaknesses and people will make mistakes.
The objective is therefore not perfect prevention. It is to ensure that a failure in one layer does not automatically become a failure of the entire system.
A compromised credential should not expose every repository. A vulnerable application should not automatically provide unrestricted access to the infrastructure, and a malicious prompt should not automatically result in a privileged action.
That is why we think about security as layers:
- Reduce the attack surface
- Protect the perimeter
- Separate secrets from applications
- Minimize privileges
- Apply Zero Trust internally
- Keep AI authorization outside the model
- Test continuously
- Reward responsible disclosure
AI is changing the security equation. It is giving defenders better tools, but it is also giving attackers better tools, and the speed of that evolution is unlikely to slow down.
The response is not to build an impenetrable system. It is to build systems where compromise is harder, detection is faster and the consequences of a single mistake are contained.
For an AI-native company, security therefore cannot be something added after the product is built. It has to become part of how the architecture itself is designed.
Security is not a feature of the system. Security is a property of the architecture.