Overview
Grizzly gives organizations a unified view of their digital assets as those assets move through internal systems, partners, and workflows.
An asset is any digital artifact your organization needs to account for:
- AI conversations and agentic workflow artifacts
- Customer, employee, or patient records
- Financial transactions and SEC filings
- Network communications
- Any data that carries compliance, legal, or operational significance
As assets move through your systems and across organizational boundaries, Grizzly tracks them in real time. Each asset carries structured metadata, including policy flags, compliance classifications, access history, originating system, and chain-of-custody records, so you always know the state of an asset, who has touched it, and whether they were authorized to do so.
The Problem Grizzly Solves
Digital assets rarely stay in one place. They move between internal services, third-party vendors, regulatory systems, and external partners, often without any unified record of where they went or who touched them. When an audit arrives or an incident occurs, the standard approach is to reconstruct what happened by stitching together logs from systems that were never designed to share information, which is slow and often incomplete.
Grizzly sits across those systems and exposes a REST API that any service can call to register, update, and query assets. Adding asset tracking to an existing workflow typically requires a single additional API call.
Core Concepts
The platform is built around four concepts: assets, accounts, API keys, and the activity feed.
Assets
An asset is a record that Grizzly tracks on your behalf. You define the metadata schema, including policy tags, compliance labels, and any custom fields your organization needs, and Grizzly maintains the full history of that asset's lifecycle: who created it, which systems have accessed it, what changes were made, and whether any access attempts were denied.
Assets can represent data stored in any system, because Grizzly functions as the authoritative record of activity around the asset rather than a primary data store.
Accounts
An Account represents an identity that interacts with your assets. Accounts can model anything: a person, a team, a service, an automated process, or a third-party partner. Every action taken on an asset is attributed to an Account, which produces an audit trail that spans every system involved.
Accounts are independent from encryption boundaries, which means you can model your full organization, including external partners, without those identities carrying inherent data access permissions.
API Keys
Each API Key belongs to an Account and carries a set of entitlements that define which KeyRings the key can access and at what permission level, such as encrypt-only, decrypt-only, or read/write. Creating an API Key with the appropriate entitlements grants access to a KeyRing, and deleting or disabling that key revokes it immediately, with no grace period. A single Account can hold multiple API Keys with different entitlements, which makes it straightforward to give auditors read-only access while operators get read/write, or to create a time-limited key for a partner without modifying anything else.
KeyRings
KeyRings define encryption and data isolation boundaries. A KeyRing groups the encryption keys used to protect a set of assets and can represent any boundary that makes sense for your organization: a team, a service, a geographic region, a regulatory domain, or a specific partner relationship. Separating assets into distinct KeyRings means that a compromise or access grant in one boundary has no impact on data in any other.
Organizations commonly create one KeyRing per partner so that partners cannot access each other's data, one per region to satisfy data residency requirements, and one per internal team when separation of duties matters. KeyRings handle key rotation, storage at rest, and matching encrypted data to the correct key version automatically, so organizations do not need to manage key lifecycle directly.
Activity Feed
The Activity Feed is a real-time, immutable record of every action across your assets. Each entry records which Account performed the action, which KeyRing and API Key were involved, what the action was (encrypt, decrypt, read, update), whether it succeeded or was denied, and a timestamp. Failed attempts appear alongside successful ones, which means a denied request is evidence that access controls are working rather than a gap in the audit trail. The feed supports compliance reporting, incident investigations, and chain-of-custody queries against any asset, account, or time range.
Compliance and Governance
Most compliance programs require some combination of chain-of-custody records, access control with immediate revocation, an immutable audit trail, data isolation between entities, and incident response capability, and Grizzly's design addresses each of those directly. Every asset carries a full history of who touched it and when. Entitlements enforce least-privilege access, and deleting an API Key revokes it instantly. The Activity Feed is complete and immutable, including denied attempts, so investigators can reconstruct exactly what happened for any asset or account across any time range. KeyRings enforce hard boundaries between partners, regions, and teams, so a breach or misconfiguration in one domain does not propagate to others.
Customer-Managed Keys
Every KeyRing is associated with a public key from a customer-provided RSA (4096-bit) asymmetric key pair. Grizzly uses this public key to encrypt all keys generated by the platform, so the raw keys are never accessible to Grizzly and can only be read by whoever holds the corresponding private key.
Organizations can manage these key pairs however they prefer, including through Grizzly's own tooling. An organization can destroy a key pair to ensure that data in a KeyRing can never be decrypted again, which is useful for time-limited datasets or when a contract ends. Organizations can also require partners to encrypt data using the organization's public key, which gives the organization full control and an audit trail over data processed entirely outside their systems. Customers always own the underlying cryptographic material, and Grizzly handles the operational complexity of managing it.
What to Read Next
If you're evaluating or designing with Grizzly
These guides cover how Grizzly fits into real-world architectures and compliance programs without requiring you to write any code.
- KeyRing Architecture Strategies — The guide walks through patterns for organizing KeyRings by team, region, partner, or regulatory domain, drawn from production deployments across industries.
- Asset Tagging — The guide explains how to attach cryptographically signed metadata to assets so they can be tracked and governed across any system or workflow.
- Security Best Practices — The guide covers production-grade recommendations for access control, key management hygiene, and incident response preparation.
If you're ready to build
Start here to get your first integration running, then follow the reference material for specifics.
- Getting Started — The guide walks through your first encrypt/decrypt operation from start to finish.
- SDK: Getting Started — The guide covers the JavaScript/TypeScript SDK for Node.js, including key caching, streaming encryption, and how the SDK abstracts the REST API.
- REST API — The reference covers the full API surface; all platform functionality is available over REST, so any language or runtime can integrate.
- Integrations: Third-Party Services — The guide covers patterns for encrypting data before it leaves your system, decrypting inbound webhooks, and building secure data-sharing workflows with external partners.