Who is accountable for relay policy and access control in a tailnet?

Accountability for Relay Policy in a Tailnet

The organisation operating the tailnet is accountable for deciding whether relays are allowed, how they are constrained, and who can use them. That accountability includes access control, deployment boundaries, and the governance decisions that determine whether traffic is routed directly or through an intermediary. If a relay is introduced without clear ownership, teams can lose visibility over traffic flow and create an unmanaged control point. The practical question is not who can configure a relay, but who owns the policy decisions that make it acceptable to run.

For most environments, that ownership sits with the same security and infrastructure functions that manage network access rules and administrative boundaries. In practice, a relay should be treated as part of the access architecture, not as an informal convenience layer. NIST Cybersecurity Framework 2.0 is relevant here because the issue is governance of a security-relevant network control, not just the mechanics of connectivity. In practice, many security teams encounter relay ownership gaps only after traffic paths have already changed and troubleshooting becomes a control problem as much as an engineering one.

How Relay Access Control Should Work in Practice

A relay changes the path traffic takes, so its policy needs to be explicit and reviewable. The accountable organisation should define who may deploy a relay, which destinations it may reach, whether it is limited to specific users or devices, and what logging or monitoring is required. If those decisions are left implicit, the relay can become a shadow routing layer that bypasses the intent of the original access design. That is why relay governance belongs alongside other access architecture decisions, rather than in a separate technical silo.

Operationally, good practice is to align relay permissions with the smallest viable trust boundary. If the relay is used for a narrow service function, its scope should stay narrow. If it affects broader traffic flows, the review bar should be higher because the blast radius increases. A relay may also affect performance and troubleshooting, so ownership should cover both security posture and operational support. The people approving access need enough context to understand whether the relay improves reachability without creating an uncontrolled path.

• Define relay approval as a policy decision, not a one-off configuration task.
• Bind relay use to named administrative ownership and documented scope.
• Review relay access the same way you review other infrastructure access paths.
• Monitor relay activity so traffic rerouting remains visible after deployment.

Where this guidance breaks down is when a relay is treated as temporary but left in place indefinitely, because the original approval context usually disappears before the control does.

Ownership Gaps, Scope Creep, and Other Tailnet Edge Cases

Tighter relay control often improves visibility, but it also adds review overhead, so organisations need to balance operational speed against the risk of creating an ungoverned traffic path.

One common edge case is delegated administration. A platform team may install or maintain a relay, but that does not automatically make it the policy owner. Governance and implementation can be split, yet accountability for the access rules should remain unambiguous. Another edge case is mixed use, where one relay serves both legitimate operational traffic and broader convenience access. That arrangement increases the chance of scope creep because the control is no longer tied to a single purpose.

There is also a distinction between technical permission and policy permission. A team may technically be able to configure the relay, but still lack authority to decide whether that traffic path should exist. When the distinction is unclear, the result is often accidental expansion of access rather than deliberate architecture. For that reason, relay governance should be reviewed as part of the same decision process that determines trust boundaries, rather than after deployment has already normalised the new path.

For readers looking at adjacent control models, CIS Controls v8 is useful where relay governance intersects with account management and secure configuration, while PCI DSS v4.0 is only relevant if the relay affects a cardholder-data environment or a similarly scoped regulated segment.

In practice, relay policy failures usually appear first as an ownership problem, and only later as a technical one, once the network path has already outgrown the decision that created it.

Risk and Threat Considerations

Relay governance creates material exposure when access policy and routing authority are unclear, because the relay becomes a security-relevant trust path that can expand reach beyond what the original design intended. The main risks are overbroad access, reduced visibility, and an unmanaged intermediary that changes how traffic is controlled and observed.

Failure mechanism: When relay permissions are not tightly bounded, an operator can unintentionally create a broader access route than intended, or an attacker can abuse the relay as a trusted path that inherits network credibility. The control fails when approval, enforcement, and monitoring are split across teams without a single owner for the policy decision.

Impact: The tailnet can lose clear segmentation, troubleshooting becomes harder because traffic no longer follows the expected path, and compromised access may reach more systems than the original policy would allow. In regulated or sensitive environments, the relay can also weaken auditability because the control point is no longer obviously governed.

Practitioner Guidance

What to verify: Confirm that one named function owns the relay policy decision, and that implementation teams cannot silently expand scope. The useful test is whether an approver can explain why the relay exists, who may use it, and what traffic boundaries it changes.

What good looks like: The relay is documented as part of the access architecture, reviewed when network boundaries change, and monitored like any other infrastructure component. If the team cannot identify where relay authority sits, the control is not mature enough to trust.

Common mistake: Treating relay setup as a technical convenience rather than a governance decision. That shortcut usually defers the ownership question until after the relay has become operationally embedded.

Practitioner takeaway: The key judgement is not whether a relay can be made to work, but whether its policy owner can still defend the traffic path, scope, and visibility after deployment.

Related resources from NHI Mgmt Group

• Who is accountable when an AI-assisted policy draft introduces an access control mistake?
• Who is accountable when an AI-generated authorization policy creates an access control failure?
• Who is accountable when an over-permissive access control policy exposes build tokens or deployment code?
• How should security teams run access reviews for non-human identities?