Data governance built for public trust: Peregrine access policies

Data governance built for public trust: Peregrine access policies | Peregrine

Data governance failures happen in an instant, but the causes are more diffuse, often preceded by years of accumulated risk. Permissive data sharing enabled by default, untracked data exfiltration events, or inconsistent audit logging each represent a single vulnerability. But taken together, they create a wide attack surface that threatens what our customers trust us to do: protect their sensitive data from unauthorized access.

Public institutions face rising scrutiny in how they handle data, as who can see a given record is a civil liberties question, not just a security setting. Peregrine’s customers carry the responsibility to know who can access what information in a transparent, auditable way. To meet that responsibility at scale, we needed to build data access controls that earn public trust and help agencies uphold their commitments to the communities they serve.

Today, we are introducing Peregrine access policies, a dedicated policy engine that scales our existing permission frameworks by pulling access controls out of application code and into an AI-assisted policy layer.

Transforming complexity into clarity

As Peregrine expands its customer base, our data governance architecture has grown more intricate. We integrate a diverse set of data sources, and access to each must be granted intentionally, accommodating different user roles, classification levels, and external data-sharing agreements.

Implementing these permissions inside application code solves customer requests quickly, but creates a governance system that is difficult to track, audit, and understand. It leaves the customer struggling to answer a fundamental question: “Who inside my organization can access what data?”

As a company scales, the immediate solve is to continue stacking controls: more user roles and organization configurations, all interacting with each other in the platform. But these incremental changes become a maze of permissions that lead to administrative overhead, support tickets, and engineering requests.

Peregrine access policies pull access controls out of application code and into a dedicated policy engine, using a hybrid AI approach to help customer administrators author, validate, and audit the rules governing who can access their data.

AI-assisted, human-validated

Peregrine is building AI tooling that transforms how our users search, synthesize, and visualize their data. However, in data governance and platform security, the non-deterministic nature of LLMs is a critical customer concern.

With this in mind, Peregrine access policies leverage the strengths of both humans and AI. Our customers think about their access requirements in plain English, so we let them articulate their access policies in the same way. An example policy could be, “Restrict access to my agency's records so only authorized personnel signing in from an approved internal network can view.”

Writing policies in natural language

Then, we use AI to generate the code that enforces the policy. For customers who opt out of AI features, policies can also be manually written in code.

Before a policy is deployed, customers can test it against their own users and data to see exactly when it allows or denies access. Once a policy is verified and enabled, every evaluation is logged with the exact code that ran and the result. Even if a policy is updated, previous versions of the code are still accessible.

Purpose-built for verifiability

In order to trust AI in this environment, we needed code generation to be reliable and correct in the narrow context of access policies. To accomplish this, we paradoxically constrained the tools that could be used, narrowing the output space and increasing verifiability.

These limitations played a key role in how we built our policy engine. We needed a language expressive enough for multi-condition policies, readable enough for a non-engineer to parse, and constrained enough that AI can reliably generate valid code. A general purpose language like Python offers more flexibility, but that expressiveness is also a liability, making it harder to analyze, validate, or audit for correctness.

After balancing the tradeoffs, we elected to build our policy engine using Cedar™, an open-source, domain-specific policy language, for several reasons:

Readability. Cedar's declarative syntax sits close to natural language, so the people who own policy (e.g., compliance officers, records managers, and IT leads) can read a rule, understand it, and confirm it matches their intent. A policy only an engineer can read is a policy no one else can validate.
Secure by design. Cedar enforces deny-by-default, where access is denied unless a policy explicitly allows it and an explicit forbid always wins over a permit. Because any unhandled conditions fail closed, safety is a feature of the system, without relying on human discipline or model behavior.
Performance. Built in Rust, Cedar evaluates policies in milliseconds, fast enough to check access throughout a session at no meaningful cost to performance. This is a critical feature for evaluations that sit on sensitive data access paths.

Cedar language output

Unblocking customers, unlocking value

Peregrine access policies give agencies new controls to strengthen their data governance. The controls fall into two groups, depending on whether access is being granted to users inside the organization or to an outside partner:

Internal access controls. Admins define who inside the organization can access what, including restricting access by email domain or disabling individual platform features, such as data exfiltration.
Partner access controls. When an agency makes data available to a data sharing partner, they can require that partner's users meet specific security standards before any data is accessed, such as connecting from a secure IP range or authenticating through an identity provider.

Both controls work the same way: They are written in plain language, tested before they go live, and audited on an immutable log that captures every policy evaluation. If a customer ever needs to verify who accessed or viewed a given record at a given time, the answer is in the logs.

Access policies in an agentic world

Across hundreds of organizations, Peregrine understands what it takes to support critical institutions without compromising trust or governance. As that work deepens, access controls have to grow more sophisticated: some records visible only to certain departments, others accessible only from a secure location. Access policies are how we move that growing complexity out of application code and into a dedicated engine built to handle it. Peregrine allows customers to author Cedar policies using AI, translating intent into an enforceable and verifiable policy language. This lowers the barrier to authoring policies while ensuring that validation and audit logging remain human-led.

In an agentic world, these investments in data governance are table stakes. Articulating what every actor, human or agent, is permitted to do, enforcing it at runtime, and logging it immutably is how AI earns a place inside the systems people depend on, while protecting the people those systems serve.

We’ve written about the principles behind how we build AI on our blog in Operational AI Requires a Foundation, and about our broader capabilities on our Trust page.

Peregrine access policies: Data governance built for public trust

Better, faster decisions in 90 days

Transforming complexity into clarity

AI-assisted, human-validated

Purpose-built for verifiability

Unblocking customers, unlocking value

Access policies in an agentic world