Who should own governance for model access when both security and engineering teams depend on it?

Why This Matters for Security Teams

Model access becomes a governance problem the moment both security and engineering rely on it for production work. If ownership is vague, teams usually compensate with shared keys, local exceptions, and manual approvals that are hard to audit and harder to revoke. That is the wrong model for OWASP Non-Human Identity Top 10 risk, because model access is usually a non-human identity control problem, not a simple developer convenience issue.

Security needs policy authority, logging, revocation, and evidence. Engineering needs fast access that does not break workflows or create secret sprawl. The governance question is therefore not who “owns” the model, but who owns the rules that determine when a workload may use it, for how long, and under what conditions. That ownership should align to NIST Cybersecurity Framework 2.0 accountability and identity governance, while still letting developers ship without handling static credentials.

NHIMG research on the Ultimate Guide to NHIs — Key Challenges and Risks consistently shows that access failures are rarely caused by one missing control alone. In practice, many security teams encounter model access abuse only after a credential has already been copied into a repo, a notebook, or a CI job.

How It Works in Practice

Shared governance works best when security and platform teams define the access model together, but implementation sits in engineering-friendly systems. Security should own the policy standard: who can request model access, which identities are allowed, what telemetry must be captured, and how revocation works. Platform or engineering teams should own the integration layer that makes those policies usable in CI/CD, runtime services, notebooks, and internal tooling.

The practical pattern is central policy, distributed enforcement. That usually means workload identity first, then short-lived credentials, then runtime authorization. Static IAM roles are too blunt for this use case because model access often changes by environment, dataset sensitivity, request type, and deployment stage. Current guidance suggests using NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor least privilege, logging, and revocation, while mapping the developer experience to automated issuance rather than manual key handling.

• Use a dedicated non-human identity for each service, pipeline, or agent that needs model access.
• Issue JIT credentials with short TTLs instead of distributing long-lived API keys.
• Enforce policy at request time so access can be narrowed by environment, data class, and purpose.
• Make revocation automatic when a job ends, a deployment is rolled back, or a token is exposed.

NHIMG’s 2024 ESG Report: Managing Non-Human Identities notes that 72% of organisations have experienced or suspect a breach of NHIs, which is a strong signal that governance has to be operational, not advisory. The right design is visible to both teams in real time, but security retains final approval over policy exceptions and emergency access. These controls tend to break down when model access is embedded in ad hoc scripts and personal developer accounts because revocation and audit trails become fragmented.

Common Variations and Edge Cases

Tighter governance often increases workflow friction, so organisations must balance developer speed against the risk of uncontrolled model usage. That tradeoff becomes sharper in research environments, rapid prototyping, and multi-team shared labs where access changes daily and the “right” owner is less obvious.

There is no universal standard for this yet, but current guidance suggests a split model: security owns policy and assurance, platform owns enablement, and engineering owns the operational context of each application. That structure works even when teams use different model providers, because the control point should remain the identity layer rather than the vendor console. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because ownership only works when lifecycle tasks such as issuance, rotation, review, and retirement are assigned clearly.

Two edge cases deserve special attention. First, if engineering owns all access decisions, policy drift usually follows because local teams optimise for speed. Second, if security owns every approval manually, developers route around the process with shadow credentials. The safer pattern is policy-as-code with shared visibility and exception handling. Where models are called from ephemeral CI jobs, serverless functions, or autonomous agents, the boundary between user access and workload access becomes especially thin, and governance must follow the workload, not the human requester.

Related resources from NHI Mgmt Group

• What do security teams get wrong about role design and access governance in ERP cloud projects?
• How should security teams use AI-assisted query building for access governance without weakening review quality?
• How should security teams implement role mining in identity governance without over-automating access decisions?
• How should security teams manage access governance when a single application has multiple instances across the business?