Four surfaces, fragmented security ownership

The research question

Who owns security when the attacker path crosses applications, identities, infrastructure and AI?

Organizations usually divide security responsibility by technology and team. Application security may sit with product security. Identity may sit with IT or IAM. Infrastructure may sit with security engineering. AI security may sit with an ML team that has only recently become part of the security program.

Those boundaries are sensible for operations. They can become problematic when the attacker path crosses them faster than the organization can coordinate them.

This article proposes a research framework for studying fragmented ownership. It does not claim that RedMaw has measured the prevalence or impact of that fragmentation.

The surfaces

Applications

Web applications and APIs contain authentication, authorization, business logic, exposed services and secrets. The crown jewel may be customer data or a privileged application function.

SaaS & Identity

Users, roles, OAuth grants, sharing, service credentials and customer-controlled SaaS posture define what a compromised identity can reach.

Internal Infrastructure

Internal systems define what happens after a foothold exists. RedMaw works outward from an authorized foothold to establish which servers, routers and switches it can access, and reports that access rather than exploiting it destructively. Deeper automation around Active Directory attack paths is planned, not current.

AI Systems

Models and AI features create prompt-injection, disclosure, jailbreak and model-change security questions. Deeper automated agent tool-abuse testing is planned.

The ownership map

A research program can begin by asking which team is accountable for each surface, which team can approve remediation and which team receives evidence when the issue crosses a boundary.

The most interesting cases are not where ownership is absent. They are where ownership exists separately and the handoff fails.

A leaked repository secret may begin as an application-security issue and become a cloud-access issue. An OAuth grant may begin as an identity issue and become a SaaS data-exposure issue. An AI feature may be owned by ML while the vulnerable control sits in the application around it.

That path crosses several common organizational owners without requiring an exotic attacker technique.

What would need to be measured

• Which team owns each surface.
• Which team owns the affected data or system.
• How findings move between teams.
• Whether evidence survives the handoff.
• Whether remediation ownership is clear.
• Whether retesting returns to the original security owner.
• Whether the organization maintains a shared finding state.
• Where approval authority changes across the path.

Qualitative interviews would be particularly useful because formal ownership charts may differ from how incidents and findings are actually handled.

Shared state as a research variable

Fragmentation is easier to manage when teams share a security object even if they use different task systems.

A finding that preserves validated evidence, affected assets, remediation context and retest state can move between teams without losing the reason it matters. A finding that becomes a copied ticket or screenshot at each handoff loses context.

The research should therefore examine not only ownership structure but also the continuity of finding state across ownership boundaries.

Handoffs deserve their own evidence model

A future study should record not only which team owns a surface, but what information is transferred when ownership changes. The security meaning of a finding can degrade when the next team receives only a severity label or a task description without the exploit evidence and reachable asset.

Useful handoff evidence would include the validated condition, affected trust boundary, remediation objective and retest requirement. Measuring how much of that context survives the handoff could reveal whether fragmented ownership is actually creating a security gap or merely reflecting a sensible division of labor.

What the research could reveal

A future study could identify recurring handoff patterns without reducing them to a single maturity score.

Some organizations may centralize validation and distribute remediation. Others may keep validation inside each technical team but share evidence and reporting. Regulated organizations may add risk and audit functions that change the ownership path again.

The goal is to understand which operating models preserve security context when the technical path crosses team boundaries.

Why this matters

Attackers do not need the organization to have a missing security team. They benefit when the organization has many capable teams that do not share the same view of reachability.

Researching fragmented ownership can help security leaders distinguish a tooling problem from an operating-model problem.

RedMaw's "Four surfaces. One adversary." model is a natural frame for the analysis, though the question stands on its own. The useful result is a clearer model of ownership, handoffs and evidence continuity that organizations can apply regardless of tooling.