Customers | AI security company
How an AI security company eliminated standing developer access across production
Key takeaways
- A fast-growing AI security company needed to govern privileged access for more than 150 engineers across GCP, production servers and SaaS applications without slowing development.
- Broad, persistent entitlements had accumulated across GCP and SSH workflows, while emergency access requirements made teams reluctant to remove standing privilege.
- Existing access processes were fragmented across Okta, PagerDuty, Slack, CLI tools and cloud-native IAM, making consistent policy enforcement and auditing difficult.
- P0 created a centralized authorization layer across the company’s existing tools, allowing engineers to request temporary, scoped access without changing how they worked.
- Within the first month, the company removed standing production access for more than 90% of engineers and moved routine and emergency privileged access to just-in-time workflows.
- Audit preparation for privileged access went from several days of gathering and correlating evidence to a few hours of reviewing a consolidated history of the privileged access governed through P0.
How did an AI security company eliminate standing developer access?
A fast-growing AI security company used P0 Security to replace broad, persistent developer access with policy-driven, just-in-time access across its production environment. P0 integrated with the company’s existing Okta, PagerDuty, Slack and CLI workflows, allowing engineers to get temporary access to GCP resources and production servers when they needed it while automatically removing that access when the approved access period ended or access was explicitly revoked.
Within the first month, the company eliminated standing production access for more than 90% of its engineering organization while preserving fast access for daily development, on-call response and break-glass situations.
Rather than adding another access system engineers had to work around, the company established a central authorization layer that governed access through the tools its teams were already using.
By the numbers: developer access at a glance
- 150+
Engineers governed through centralized access policy - 90%+
Standing production access eliminated within the first month - <1 day
Initial deployment and integration with the company’s existing identity and engineering workflows - Hours, not days
Time required to prepare privileged access evidence for audit
About the company: securing AI while building it
The customer is a fast-growing AI security company with more than 150 engineers building and operating cloud-native products across Google Cloud Platform.
Its engineering teams work across dozens of GCP projects, production servers and SaaS applications, with developers, platform engineers and on-call responders regularly requiring privileged access to troubleshoot systems, deploy changes and respond to incidents.
The company already relied on Okta for workforce authentication and PagerDuty, Slack and CLI-based tools as part of its engineering workflows. The problem was not authentication. It was controlling what happened after an engineer authenticated and needed privileged access to production.
As the company grew, so did the number of users, systems and access paths the security team needed to govern.
The challenge: standing access had become the easiest way to keep engineering moving
The security team wanted to reduce persistent privileged access across GCP and production servers, but simply removing access was not practical.
Engineers needed production access frequently enough that broad entitlements had become the path of least resistance. On-call responders also needed confidence that they could reach critical systems immediately during an outage.
The result was a familiar tradeoff: security could tighten access and risk slowing engineering, or leave standing privilege in place and accept the additional exposure.
Neither option was sustainable.
1. Broad production permissions stayed in place because engineers might need them
Engineering teams had accumulated persistent access to GCP projects, infrastructure and production servers over time.
Many of those permissions were not needed continuously. They existed because an engineer might need them during a deployment, troubleshooting session or incident.
That distinction matters. An engineer who needs privileged access for 30 minutes during an incident does not necessarily need the same privilege available every hour of every day.
But without a reliable way to grant access quickly when needed, removing standing access created operational risk of its own.
2. Emergency access made least privilege harder to enforce
On-call engineers used PagerDuty to respond to production incidents.
During an outage, waiting for a security administrator to approve a ticket was not an option. Responders needed immediate access to diagnose and fix the problem.
To make sure engineers were never blocked during an emergency, organizations often leave broader permissions permanently assigned than users require during normal operations.
The company wanted to remove that tradeoff.
An on-call engineer needed a reliable path into production, but that did not mean every on-call engineer needed permanent privileged access before an incident occurred or after it ended.
3. Access policy was fragmented across tools and systems
Authentication happened through Okta. Incident response started in PagerDuty. Engineers worked through Slack and the CLI. Actual permissions lived inside GCP and the systems engineers needed to reach.
Each component handled part of the access chain, but none provided one place to answer the full authorization question:
Who is requesting access, what are they trying to access, why do they need it, what level of privilege should they receive and how long should they keep it?
The company needed to preserve its existing tools while applying a consistent policy across them.
4. Audit evidence had to be reconstructed after the fact
Privileged access reviews required the security and engineering teams to correlate information from multiple systems.
Authentication logs might show who signed in. GCP logs might show what account performed an action. PagerDuty might provide incident context. Approval information could live somewhere else entirely.
The team could reconstruct what happened, but doing so took several days for a typical audit request and pulled engineers into evidence gathering.
The company wanted the access process itself to create the audit trail.
The solution: one authorization model across GCP, SSH and emergency access
The company selected P0 Security to establish a centralized policy and authorization layer across its existing environment.
P0 integrated with Okta to preserve the company’s existing SSO and MFA requirements, while adding runtime authorization for privileged access. Instead of treating successful authentication as permission to use a standing entitlement, P0 evaluated each access request independently.
For every request, P0 could determine who was asking, which resource they wanted to reach, what level of access was appropriate, why the access was needed and how long it should remain active.
The company rolled out the initial environment in less than a day without deploying bastions or requiring engineers to adopt a new access workflow.
1. Replace standing production access with just-in-time access
The company began by identifying production access that engineers did not need continuously.
Rather than permanently assigning those entitlements, P0 allowed engineers to request them when needed.
A developer troubleshooting an application could request temporary access to the relevant GCP resource or production server. P0 evaluated the request against policy, granted only the required entitlement and automatically revoked it when the approved access window ended.
Within the first month, more than 90% of engineers who previously held some form of standing production access had moved to just-in-time access.
| Before P0 | After P0 |
|---|---|
| Broad production entitlements remained assigned because engineers might need them | Privileged access is granted when needed and automatically revoked |
| Access duration was determined by how long permissions remained configured | Each P0-governed temporary grant had a defined duration tied to the request |
| Engineers frequently had access beyond the scope of the immediate task | Access can be scoped to the resource and task being performed |
| Security had to periodically review accumulated access | Policy governs privileged access each time it is requested |
2. Keep Okta for authentication and add authorization at runtime
The company did not need to replace Okta.
Okta continued to establish the engineer’s identity and enforce authentication requirements such as SSO and MFA. P0 then handled the next decision: what that authenticated engineer should be permitted to access under the current policy and context.
This separation allowed the company to preserve its existing identity architecture while applying much more granular control to privileged access.
Authentication answered who the person was.
P0’s authorization policies determined what that person could do, to which resource and for how long.
3. Turn PagerDuty into the context for emergency access
The company also connected P0 to its PagerDuty workflows.
When an engineer was actively responding to an incident, PagerDuty provided meaningful context for the access decision. P0 could use that context to allow an on-call responder to receive the production access necessary for the incident without requiring the same privilege to remain assigned permanently.
Engineers kept the emergency workflow they already trusted. Security gained runtime policy enforcement, defined access duration and a record connecting the engineer, incident and resulting access.
The privilege could be removed when the approved access period ended, the incident context no longer applied or access was explicitly revoked.
That allowed the company to eliminate much of the standing access it had previously retained as insurance against an outage.
4. Let engineers request access from Slack and the CLI
Changing the security model did not require engineers to change how they worked.
Developers could initiate access requests from Slack or the CLI rather than opening a separate ticket or signing into another administrative console.
For common low-risk requests, policy could automatically approve access. More sensitive requests could require additional approval or context before access was granted.
The result was a policy-driven process that was often faster than the standing-access model it replaced because engineers no longer needed to hunt down an administrator when their existing permissions were insufficient.
5. Create the audit record as access happens
Privileged access governed through P0 ran through a common authorization process.
For access governed through P0, the audit history associated the requesting identity and resource with the supplied justification, applicable approval or policy decision, granted entitlement, grant time and revocation time.
Instead of reconstructing privileged access activity months later, the security team can provide its GRC team with a chronological record of who received access, why they received it and how long they retained it.
Audit preparation that previously required several days of pulling logs and coordinating with engineering can now be completed in a few hours.
“We needed to reduce standing access without creating another high touch process that engineers would inevitably work around. With P0, we could enforce policy across our existing workflows to minimize friction while making access more secure and easier to audit.”
Security Engineering Leader, AI Security Company
The results: Zero Standing Privilege without slowing engineering
Within the first month of deployment, the company had materially changed how privileged production access worked:
- More than 90% of engineering standing production access was eliminated
- 150+ engineers were brought under a common privileged access policy
- GCP and SSH access moved to just-in-time, time-bound workflows
- PagerDuty-based emergency access no longer required permanent break-glass privileges
- Okta remained the authentication layer, avoiding a disruptive identity migration
- Engineers could request access through Slack and the CLI instead of relying on manual tickets
- Evidence for P0-governed privileged access became available through a consolidated audit history
- Audit preparation for access reviews dropped from several days to a few hours
The larger change was not simply the removal of permissions.
The company moved from a model in which engineers accumulated access in advance to one in which privilege is evaluated and granted when there is a legitimate reason to use it.
That allowed the security team to reduce standing privilege without turning security into a bottleneck for engineering.
Why authentication alone does not solve privileged access
Authentication establishes identity. It does not determine whether every action that authenticated identity can technically perform should be permitted in the current situation.
That distinction becomes particularly important in modern cloud environments.
An engineer may authenticate through Okta and belong to a legitimate engineering group while still not needing administrative access to every production GCP project at all times.
Traditional access models often address this by assigning roles in advance. Once assigned, the privilege remains available until someone removes it.
Runtime authorization changes the decision point. Instead of asking only whether the user has an assigned role, the organization can evaluate the current request using identity, resource, task, business context, requested privilege and duration.
The resulting access can then be granted temporarily and removed when it is no longer required.
Why emergency access does not require standing privilege
Break-glass access is often treated as an exception to least privilege because organizations cannot risk blocking responders during an outage.
But reliable emergency access and permanent privileged access are not the same thing.
A policy-driven model can recognize that an engineer is the active PagerDuty responder, determine which production resources are relevant and grant temporary elevated access for the duration of the incident.
That gives responders a dependable path to production without leaving the same privilege exposed between incidents.
For this AI security company, that distinction was central to removing standing privilege. The security team did not have to choose between locking down production and keeping incident response fast.
From human access to workloads and AI agents
The company initially adopted P0 to solve human privileged access, but the underlying problem is already expanding.
AI agents and workloads increasingly need access to many of the same cloud resources, applications and production systems used by engineers.
Giving an agent a credential or authenticating it establishes its identity. It does not answer whether that agent should be allowed to perform a specific action on a specific resource in the context of the current task.
The centralized authorization model the company established for engineers creates a foundation for applying similar controls to non-human identities and AI agents.
Instead of building an entirely separate security model for each new identity type, the company can extend policy-driven access across users, workloads and agents while preserving the context necessary to understand who or what initiated each action.
More broadly, the same runtime access control model can be applied across users, workloads and AI agents. Agentic workflows require additional context, including the identity that originated the task, the acting agent, the requested tool, the target resource and the attempted action, but they do not require an entirely separate authorization model.
Standing privilege is not the price of developer velocity
Organizations often tolerate standing production privilege because removing it sounds like an engineering productivity problem.
It does not have to be.
The practical question is whether engineers can obtain the access they legitimately need faster than they can work around the security process.
By keeping Okta, PagerDuty, Slack and CLI workflows intact while changing how privileged access was granted underneath them, this AI security company removed most standing production access without introducing a new high-touch process.
Engineers still get into production when they need to.
The difference is that the privilege no longer needs to be waiting for them when they do not.
See how P0 can help your organization eliminate standing privilege: request a demo
Frequently asked questions about just-in-time developer access
What is just-in-time privileged access?
Just-in-time privileged access grants elevated permissions when a user needs them instead of assigning those permissions permanently. Access can be limited to a particular resource, privilege level and duration, then automatically revoked when the approved period ends.
What is standing privilege?
Standing privilege is access that remains continuously assigned whether or not the user currently needs it. For production systems, standing privilege increases exposure because a compromised account can immediately use whatever permissions are already available to it.
How can companies remove standing developer access without slowing engineers?
Companies can replace permanent production entitlements with policy-driven access workflows that allow engineers to request the privileges they need when they need them. Integrating those workflows into tools engineers already use, such as Slack, the CLI and incident-response systems, avoids adding a separate manual ticketing process.
How does P0 work with Okta?
Okta can continue to authenticate the user and enforce requirements such as SSO and MFA. P0 adds an authorization layer that determines what the authenticated user may access, which privileges should be granted and how long those privileges should remain active.
Can PagerDuty be used for just-in-time emergency access?
Yes. Incident and on-call context from PagerDuty can be incorporated into access policy so an active responder can receive temporary production access during an incident. That access can then be revoked when the incident or approved access period ends.
Does just-in-time access eliminate break-glass access?
It changes how break-glass access is implemented. Instead of leaving emergency privileges permanently assigned, organizations can establish a reliable policy-driven path for responders to obtain elevated access when an emergency occurs.
Can developers request P0 access from Slack or the CLI?
Yes. P0 can integrate privileged access requests into engineering workflows such as Slack and the CLI so users do not need to move to a separate access-management interface every time they need temporary access.
What information should a privileged access audit trail contain?
A useful privileged access record should show who requested access, which resource they requested, what privilege was granted, why access was needed, what policy or approval allowed it, when it was granted and when it was revoked.
What is the difference between authentication and runtime authorization?
Authentication determines who or what an identity is. Runtime authorization determines whether that identity should be permitted to perform the requested action under the current policy and context. Successful authentication does not necessarily mean every technically available action should be allowed.
Can the same access model be used for AI agents?
The same core principles apply, but agentic access introduces additional context. Policy may need to consider the originating user, the agent identity, requested tool, target resource and action being attempted. A centralized runtime authorization layer can provide a foundation for enforcing those decisions across human and agent access.