Written by Jaiz Anuar

Attack Surface Is Designed Long Before Go-Live

By the time a system reaches production, much of its attack surface already exists. Architecture determines which systems connect, which identities are trusted and how much authority compromise can inherit.

Security teams often talk about attack surface as though it appears when a system reaches production.

The application goes live. Vulnerability scanning begins. Internet exposure is reviewed. Firewall rules are checked. Security monitoring is enabled.

But by that point, much of the attack surface has already been created.

It was created when the architecture decided which systems could communicate, which identities would be trusted, which APIs would be exposed, which third parties could connect, how production and non-production would be separated, and how much authority each component would receive.

In other words, attack surface is often designed long before go-live.

Attack Surface Is More Than Internet Exposure

The term is often associated with public-facing systems, open ports and vulnerabilities.

That is only part of the picture.

A modern enterprise attack surface also includes identities, APIs, cloud permissions, SaaS integrations, machine credentials, CI/CD pipelines, partner connections, AI agents and trusted software dependencies.

A system may not be exposed directly to the internet and still have a large attack surface.

An internal API with excessive privilege is an attack surface.

A service account shared across multiple applications is an attack surface.

An AI agent connected to several MCP servers is an attack surface.

A third-party integration with broad access is an attack surface.

The more trust and authority the architecture creates, the more opportunity an attacker may inherit when one component is compromised.

Architecture Decisions Create Future Exposure

Consider a simple design decision.

Two systems need to exchange data.

The easiest approach may be to create a broad service account, allow wide network access and connect the systems directly.

The integration works.

The project moves forward.

But the architecture has also created a future attack path.

If that service account is compromised, what can it reach? If one system is breached, can the attacker move into the other? Can the connection be isolated quickly without affecting unrelated services?

These questions should be answered during design.

Not after deployment.

This is closely related to the principle in Every Trust Relationship Is An Attack Path. Every connection is not only a connectivity decision. It is also a trust decision.

And every trust decision can increase attack surface.

Excessive Authority Is Attack Surface

Not all attack surface is created by connectivity.

Some of it is created by privilege.

An application may only need to read customer records but is given read-and-write access.

A CI/CD pipeline may only need to deploy one application but receives broad cloud permissions.

An administrator may manage one platform but is given enterprise-wide privileges.

An AI assistant may only need to retrieve documents but is allowed to invoke tools that can modify data.

These decisions may be convenient during implementation.

They also increase the consequences of compromise.

This is why the principle in The Strongest Architecture Is The One That Limits Blast Radius matters before go-live.

Least privilege does more than protect access.

It reduces the amount of attack surface created by each identity and workload.

Integration Design Matters

External integration is another area where attack surface is often created early.

A business partner needs access.

A firewall rule is opened.

A VPN is established.

An API credential is issued.

The integration works.

But the design may also introduce dependency on another organisation's security posture.

As discussed in Your Trusted Business Partner Is Compromised. Are You Next?, a trusted partner can become an attack path if the connection is too broad or too difficult to isolate.

A defendable architecture should therefore ask:

What exactly does the partner need to access? Can the integration terminate in a controlled zone? Can the credential be revoked quickly? Can abnormal behaviour be detected? Can the partner be isolated without interrupting other critical services?

Those are architecture questions.

They define attack surface before the first production transaction occurs.

Cloud Can Reduce Attack Surface Or Multiply It

Cloud architecture creates the same choice.

An organisation can use cloud capabilities to create strong boundaries, separate accounts, short-lived identities and tightly scoped services.

Or it can recreate a flat data-centre model in the cloud.

Shared credentials, broad network reachability, overprivileged roles and weak separation between production and non-production can create a much larger attack surface than the original design intended.

This is why the argument in Three-Tier Architecture Was Built for Yesterday. Future Architecture Must Be Designed to Survive. matters.

Future architecture should not only ask whether a system can scale and integrate.

It should ask how much of the environment becomes exposed when one component fails.

That decision is made during architecture.

AI Expands Attack Surface Through Capability

AI introduces another dimension.

The attack surface is no longer only the model or the prompt.

It includes everything the AI can reach.

A model that only generates text has one risk profile.

An AI agent that can query data, call APIs, access repositories, invoke MCP tools and perform transactions has a much larger attack surface.

This is why The AI Gateway Should Govern Trust, Tokens And Tools is not only about AI governance.

It is also about attack-surface control.

Every model connection, MCP server and tool invocation should be deliberate.

The architecture should decide which capabilities are actually required.

AI capability should not automatically become AI authority.

Security Controls Cannot Fully Repair Poor Architecture

This is the uncomfortable part.

Once a system is built, security teams can add controls.

They can deploy EDR.

They can enable monitoring.

They can add DLP.

They can tighten firewall rules.

They can improve logging.

All of that helps.

But security controls may not fully compensate for architecture that created excessive trust, privilege or dependency from the beginning.

As discussed in Security Architecture Protects The Business; Security Controls Protect The Technology, controls answer how something is protected.

Architecture determines what needs to be protected, what can reach it and how much damage can occur when protection fails.

That is why architectural decisions matter so much.

Architecture Reviews Should Ask Different Questions

A good architecture review should therefore look for attack surface before implementation begins.

Not only:

Is the traffic encrypted?

Is MFA enabled?

Is logging configured?

But also:

Why does this connection exist? Does the system need this level of privilege? Can this identity reach more than the business requirement demands? Can the integration be isolated? What happens if the trusted component is compromised? Can the design operate safely in degraded mode?

These questions challenge the architecture before expensive dependencies become permanent.

That is the point of security architecture.

Not to approve controls at the end.

To shape the design before risk becomes embedded.

Final Thoughts

Attack surface is not something security discovers only after deployment.

Much of it is created during architecture.

It is created when trust is broad.

When identities are overprivileged.

When integrations are too open.

When cloud environments are too flat.

When AI agents are given unnecessary capability.

When recovery depends on the same systems that may be compromised.

By go-live, many of those decisions may already be expensive to change.

That is why the best time to reduce attack surface is not after the first vulnerability scan.

It is when the architecture is still being designed.

Attack surface is designed long before go-live.

Question assumptions. Share knowledge. Build trust.