Who is accountable when security policy is applied inside the work environment instead of the network perimeter?

Why This Matters for Security Teams

When policy moves from the network perimeter into the work environment, accountability shifts from gatekeeping infrastructure to the teams that define runtime access, exceptions, and evidence. That change matters because browser sessions, devices, SaaS apps, and AI agents all make decisions outside the old perimeter model. Current guidance from NIST Cybersecurity Framework 2.0 and NHIMG’s audit guidance for NHIs points to ownership, logging, and policy enforcement as core control functions, not secondary operations.

For security leaders, the practical risk is that “policy in the work environment” can become everyone’s problem and nobody’s responsibility. Identity, endpoint, app, and platform teams must coordinate because access is evaluated where work happens, not where packets enter the network. That requires clear control ownership for policy design, exception handling, monitoring, and review, especially when secrets, OAuth grants, and service accounts are involved. In practice, many security teams encounter accountability gaps only after a mis-scoped exception or leaked credential has already been used inside a trusted app.

How It Works in Practice

In a perimeter model, the network decides what is allowed. In a work-environment model, the application, identity layer, or policy engine decides at request time whether a user, device, service account, or AI agent can proceed. That means accountability sits with the teams that operate the policy logic and the evidence chain. For NHIs, this is especially important because static credentials and broad entitlements do not map well to real workflow use. NHIMG research shows that 97% of NHIs carry excessive privileges and that 71% are not rotated on schedule, which is why lifecycle control matters as much as access control.

Operationally, security teams should separate three responsibilities:

• Policy definition: security and identity owners set the rules for least privilege, conditional access, and runtime approval.
• Policy enforcement: application, endpoint, and workload control planes evaluate access in context, using signals such as device posture, session risk, or task scope.
• Policy assurance: audit, detection, and governance teams verify that exceptions, overrides, and logs are complete and reviewable.

For machine and agent workloads, best practice is evolving toward short-lived credentials, workload identity, and policy-as-code rather than long-lived secrets. NIST SP 800-207 Zero Trust Architecture supports continuous verification, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides control families for access enforcement, auditability, and accountability. NHIMG’s Top 10 NHI Issues also shows how often secrets exposure and privilege sprawl undermine these controls before teams notice. These controls tend to break down when ownership is split across too many platform teams because exception tracking and logging become inconsistent.

Common Variations and Edge Cases

Tighter policy enforcement in the work environment often increases operational overhead, requiring organisations to balance security assurance against developer friction, support load, and business continuity. That tradeoff becomes sharper when policy is applied inside browsers, SaaS platforms, or AI tools that users can reach from unmanaged devices. There is no universal standard for this yet, but current guidance suggests that accountability should follow the control point: if the app or policy engine makes the decision, the teams running that control must own its accuracy, reviewability, and rollback process.

Edge cases usually appear where multiple identities intersect. A human user may authenticate once, but the session can delegate to an API key, a service account, and then an AI agent with tool access. In those cases, ownership must extend across identity, application security, and platform operations so that each handoff is logged and attributable. This is especially true for OAuth-connected vendors and third-party integrations, where NHIMG research reports very limited visibility into external connections and a large share of organisations planning NHI investment within the next year. For accountable governance, teams should also document who approves exceptions, who revokes access, and who signs off on residual risk, using the guidance in NHIMG’s lifecycle guidance for managing NHIs alongside NIST SP 800-207 Zero Trust Architecture.

Related resources from NHI Mgmt Group

• How should security teams decide whether to build authorization logic inside applications or externalize it to a centralized policy layer?
• Who should be accountable for API policy and compliance when development moves faster than security reviews?
• Who is accountable when physical access decisions do not match HR status or security policy?
• How should organisations tailor GenAI security controls for each application instead of relying on one global policy?