You can do everything right in your application code and still have a security problem in production.
Your dependencies, deployment platform, credentials, and third-party integrations all influence the security of the system you're building.
Recent PHP vulnerabilities and Railway's security incident brought this into focus for me. They involved different types of risk, but both are reminders that production security extends beyond the code we write.
The security boundary is bigger than your application
Consider a typical application deployed to production.
It connects to a database, uses cloud storage, calls external APIs, and relies on a deployment platform to build and release new versions. An AI-powered application might also connect to multiple model providers and agent tools.
Each connection introduces a dependency. Each credential grants some level of access. Each integration creates another boundary that needs to be understood and managed.
The important question isn't just whether your application code is secure.
It's what could happen if one of those dependencies or credentials were compromised.
If a service has unrestricted access to your production database, a compromised credential could expose far more than that individual service. If development and production share powerful credentials, a problem in one environment could affect the other.
The impact depends on the permissions granted, the systems connected, and the controls in place.
This is where architecture and security meet.
Security decisions that matter in production
1. Apply least privilege
Every service, user, and automated workflow should have only the permissions it needs.
A background worker that processes notifications probably doesn't need administrative access to your database. A deployment token shouldn't automatically have access to every repository and environment.
Reducing unnecessary permissions limits the potential impact of compromised credentials.
2. Treat dependencies as part of your attack surface
Applications inherit risk from the libraries, runtimes, base images, and services they depend on.
Maintain an inventory of production dependencies, monitor security advisories, and automate vulnerability scanning where practical.
When a critical vulnerability is disclosed, you need to identify affected versions, assess exposure, and prioritise remediation. Updating dependencies should be a repeatable operational process, not an occasional maintenance task.
3. Protect credentials and isolate environments
Production secrets should not be committed to source control or casually shared across development, staging, and production.
Use a secrets manager or your platform's supported secret-management mechanism. Restrict access, prefer short-lived credentials where supported, and establish a process for revoking and rotating credentials when exposure is suspected.
Also consider what happens when a deployment platform or developer account is compromised. Access to secrets should be limited enough that a single incident cannot expose every system.
4. Design for a compromised component
Security controls should assume that individual components can fail or become compromised.
Network restrictions, workload isolation, scoped credentials, audit logs, and independent access controls can help prevent a local incident from spreading across the entire environment.
This is the principle of reducing the blast radius.
The goal isn't to assume every provider is untrustworthy. It's to avoid giving any single component more control than it needs.
5. Make recovery part of the design
Preventive controls are essential, but they cannot eliminate every incident.
Engineering teams also need a reliable way to revoke credentials, patch affected systems, investigate suspicious activity, restore data, and deploy a trusted version of the application.
Backups should be tested. Rollback procedures should be understood. Emergency deployment processes should be documented and, where possible, practised.
A recovery plan is only useful if it works under real conditions.
Why this matters even more for AI applications
AI systems often introduce additional external dependencies: model APIs, vector databases, retrieval services, agent tools, and third-party integrations.
An agent may have access to tools that can read data, update records, or trigger business operations. Securing the model API key is only one part of the problem.
Tool permissions, data access, input validation, approval requirements for sensitive actions, and auditability all matter.
An AI agent should not automatically inherit broad permissions simply because it needs to complete a task.
The same principle applies to the rest of the system: grant the minimum access required, make sensitive actions explicit, and keep enough visibility to understand what happened when something goes wrong.
Engineering for failure
We cannot eliminate every vulnerability or guarantee that every platform will remain secure.
What we can do is control the access we grant, reduce unnecessary dependencies, limit how far a compromise can spread, and prepare to recover.
These decisions may not be as visible as a new feature or a performance improvement. But they are part of building software that can be operated safely in production.
Good engineering isn't just about building systems that work. It's about understanding what could go wrong and designing them to handle it.
I'd be interested to hear how other engineers approach this; when designing a production system, how do you decide where to invest in security controls and how much access each component should have?
Top comments (0)