What breaks when access control is based only on integration diagrams?

Integration Diagrams Describe Intent, Not Enforced Authority

When access control is treated as “what the diagram says,” the control inherits the diagram’s limitations. Integration views are useful for planning, but they do not prove who can call what at runtime, which identity is presenting the request, or whether the request is being routed through a broker, plugin, gateway, or agent tool path that the diagram never captured.

That gap matters most when the system can choose paths dynamically. The security boundary is the effective request path, not the architectural slide, so the real question is whether authorisation is enforced at the decision point that actually handles the call.

Runtime controls need to be attached to the Authorisation Models Guide, not just to documentation that shows the intended relationship. The same principle appears in IAM and IGA Basics: approval and entitlement records only help when they match the live access path.

What Breaks at Runtime When the Diagram Is the Policy

The first break is authorisation drift. A diagram may show one approved system-to-system connection, but the live workflow can fan out to extra tools, APIs, queues, or data stores. If access decisions are not made per request, a single approved integration becomes a broader trust corridor than was intended.

The second break is observability. Logging often follows the documented system owner rather than the actual caller and target chain, so investigations miss the intermediate hop where privilege was exercised. That makes it hard to answer a basic incident question: which component really acted, on whose behalf, and against which resource?

The same failure pattern is why AI Agent Authorisation Guide emphasises per-action policy decisions and task-scoped access. For workflows that can branch at runtime, static integration approval is too coarse unless it is backed by live enforcement and audit trails.

How Practitioners Should Test the Access Control Boundary

The useful test is to compare the documented integration with an observed request path under real execution. If the caller, target, context, or permission set changes during execution, then the diagram is not the control boundary and should not be used as the basis for access approval.

In practice, this means checking whether the control point can see the current actor, the current resource, and the current action before it allows the call. If any of those are inferred only from the diagram, trust has already been granted too early.

For systems that retrieve content or actions dynamically, Permission-Aware RAG Guide illustrates the same requirement: permissions must be applied at the point of retrieval or invocation, not assumed from the existence of a nominally approved integration.

Risk and Threat Considerations

Diagram-based access control creates blind spots that attackers and misbehaving automations can exploit by taking an unapproved path that still looks legitimate on paper. The result is a control failure that is easy to miss in review because the documentation appears compliant while the runtime path is not.

Failure mechanism: The documented connection is treated as evidence of authorised use, so a workflow can pivot to additional tools, APIs, or data sources without a fresh authorisation decision or complete logging.

Impact: Excess privilege, data overexposure, and weak forensic traceability can follow, especially when the actual call chain crosses trust boundaries that the diagram never modelled.

Practitioner Guidance

What to verify: Validate access against observed runtime traces, not only architecture diagrams. A control is only trustworthy if the request path, calling identity, and target resource all match the approved policy at execution time.

Common mistake: Treating integration approval as access approval. That shortcut works only when the path is fixed and all privilege is explicit; it fails when orchestration, agents, or middleware can change the route dynamically.

What good looks like: Each sensitive action has an enforceable decision point, a logged caller, and a bounded resource scope, so a change in path causes either a denied request or a clearly attributable audit event.

Practitioner takeaway: If the policy is derived from the diagram instead of from the live request, the access model is already weaker than the architecture suggests.

Related resources from NHI Mgmt Group

• What breaks when push-based MFA is the main control for privileged access?
• What breaks when role-based access control depends on too many exceptions?
• What breaks when role-based access control is too coarse for support operations?
• What breaks when role-based access control is not regularly reviewed and updated?