Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Organizations are rapidly integrating AI into everyday business operations. Teams are using Microsoft Copilot and Gemini to summarize meetings, developers are accelerating software delivery with coding copilots and customer service teams are deploying AI-powered chatbots to improve response times. While these initiatives are viewed through the lens of productivity and innovation, they are also reshaping organizations’ identity environments in ways that frequently go unnoticed.

The main difference between AI governance and AI compliance is that AI governance is the internal framework an organization develops to manage AI responsibly, while AI compliance is how organizations demonstrate to external regulators that they’re adhering to applicable laws and regulations. These two terms get used interchangeably, but they solve different problems. With compliance alone, an organization can satisfy regulators without meaningfully controlling how its AI behaves.

Earlier this year, a bill arrived from one of 1Password’s AI vendors for 5x the value of the original contract. The initial agreement came in below a certain threshold, so it never reached the right approvers for review. By the time it did, we had a much clearer understanding of how quickly AI costs can add up.

AI agents are doing more than just generating code. Increasingly, they are working autonomously on complex coding challenges, touching production APIs, databases, and infrastructure across development environments, often without thorough human review. To perform these operations and access multiple systems, agents rely on developer secrets and non-human identities (NHI). But often, developers lack a secure way to share these secrets, leading to overprivileged, invisible access.

In our last post, we shared how we began to scale our security code review process with SAGE. We discussed how we gathered historical Product Security (ProdSec) review records to create a 1Password-specific ruleset, the three-stage Finder/Critic/Judge pipeline, and the limitations of our v1 implementation.

Every security team has tried to trace a credential access event back to a specific workload, and received nothing but a "service account." That service account probably had access to an entire vault, and its audit trail doesn’t tell you which repo triggered the request, which specific credential was accessed, or whether the workflow still has access. When an auditor asks, or an incident occurs, that's not a good place to be.

1Password surveyed 500 American IT and security professionals and 500 developers to learn how organizations are adopting and governing AI for their most technical workers.