Who is accountable when extensible platform code can spread across tenant applications?

Why This Matters for Security Teams

When extensible platform code can move from one tenant application into another, the issue is no longer just application design. It becomes an accountability problem for privileged change, trust boundaries, and operational containment. Security teams need to know who can authorize code propagation, who can review the blast radius, and who owns the control failures when a widget behaves like an active component rather than static content. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames access control, change management, and auditability as control objectives rather than informal assurances.

The practical risk is that many organisations treat extensibility as a product feature while inheriting a security model closer to code deployment. Once tenant applications can share execution paths, the question is not only whether the code is trusted, but whether the governance model can prove that trust continuously. In practice, many security teams encounter the failure only after a tenant-to-tenant alteration has already created exposure, rather than through intentional design review.

How It Works in Practice

Accountability should be assigned at two levels. First, platform owners are responsible for the extensibility architecture: what code can run, where it runs, how it is signed or approved, and what isolation exists between tenants. Second, security governance teams are responsible for the policy decision on whether cross-application modification is allowed, and if so, under what monitoring and escalation rules. This is a control decision, not just an engineering preference.

In mature environments, extensible code is treated as a privileged capability. That usually means:

• Defining a trust model for each executable widget, plugin, or extension.
• Requiring approval workflows for cross-application changes.
• Logging who published, modified, or invoked shared code paths.
• Separating developer convenience from production privilege.
• Reviewing whether an extension can read data, call APIs, or alter another tenant’s logic.

For identity-heavy platforms, the same logic applies to non-human identities that sign, deploy, or orchestrate extensions. If an automation account can modify code across tenant boundaries, it should be governed like any other high-value identity, with clear ownership, conditional approval, and periodic recertification. Where agentic AI generates or adapts extensible code, current guidance suggests treating that pipeline as part of the software supply chain, with human sign-off before deployment. The most relevant companion control families are the NIST control catalog and the threat-centric guidance in MITRE ATT&CK, because both help map how legitimate access becomes an abuse path.

These controls tend to break down when a low-code platform allows tenant-authored extensions to execute with shared service credentials, because the platform owner may not see the effective privilege boundary until after abuse has spread.

Common Variations and Edge Cases

Tighter control over extensibility often increases delivery friction and support overhead, requiring organisations to balance platform agility against containment and auditability. That tradeoff is especially visible in SaaS marketplaces, embedded app frameworks, and internal developer platforms where teams expect reuse across tenants.

There is no universal standard for this yet, but current guidance suggests three recurring edge cases. First, if extensions are purely declarative, the risk profile is lower than for executable code, though data access still needs review. Second, if the platform supports customer-managed extensions, accountability must be split between the provider’s control plane and the customer’s deployment governance. Third, if extensions are generated or updated by AI systems, the governance model should include output validation and provenance checks rather than assuming the code is safe because it was machine-produced.

In identity terms, cross-tenant extensibility should be thought of as an access problem as much as a code problem. That means platform teams need explicit owner assignment, while security teams decide whether the capability is acceptable at all. For broader software resilience, the CISA Secure by Design guidance is useful for reinforcing that security responsibilities should be built into the product model, not added after deployment. Where payment data or regulated workloads are involved, review expectations may also be shaped by PCI DSS v4.0. The edge case that causes the most confusion is when “configuration” changes actually alter executable logic, because teams often classify that as administration instead of privileged code modification.

Related resources from NHI Mgmt Group

• Who is accountable when a workflow platform vulnerability leads to code execution?
• Who is accountable when identity provider trust is mis-scoped across applications?
• Who is accountable when identity data drifts across SAP and connected applications?
• Who is accountable when consumer deletion rights are centralised across a regulator-run platform?