What Inkrypt.ai Encrypts (And What It Does Not)

1. Executive Summary

Inkrypt.ai delivers application-level encryption through lightweight SDKs that integrate directly into modern applications. Unlike perimeter-only or infrastructure-focused encryption solutions, Inkrypt encrypts sensitive data elements at the moment they are created or processed by the application—before the data is stored, logged, transmitted, or shared with downstream services.

Inkrypt operates alongside existing enterprise security controls rather than replacing them. Transport-level security (TLS / mTLS), disk and volume encryption, HSMs, and cloud provider security remain intact and continue to serve their intended roles. Inkrypt focuses on protecting the data itself, regardless of where it travels or resides.

By encrypting data at the application layer, Inkrypt significantly reduces the blast radius of breaches, limits insider threats, and ensures that sensitive data remains protected even in compromised environments.

Core principle:

Inkrypt encrypts data — not pipes, disks, or networks.

2. Encryption Coverage Model

Inkrypt follows a shared responsibility encryption model, clearly defining what Inkrypt secures and what remains under standard infrastructure or platform security controls.

2.1 Encryption Responsibility Matrix

Layer Encrypted by Inkrypt SDK Notes
Authentication secrets Yes Tokens, refresh tokens, secrets
Business data Yes Fields, payloads, documents
Database fields Yes App-level field encryption
Files / object storage Yes Encrypted before write
API payload fields Yes Selective field encryption
Data in transit No TLS / mTLS
Disk / volume encryption No OS / cloud
Network traffic No TLS / IPsec

Inkrypt intentionally avoids duplicating controls that are already well-addressed by established standards. This ensures clean architecture, minimal overhead, and maximum interoperability.

3. Authentication & Identity Data

Authentication systems are a prime target for attackers. Inkrypt strengthens identity protection by encrypting authentication artifacts at rest, without interfering with authentication flows or standards.

3.1 What Inkrypt Encrypts

Inkrypt SDKs can encrypt:

  • OAuth 2.0 access tokens and refresh tokens (at rest)

  • OIDC ID tokens and session metadata

  • API keys and service-to-service credentials

  • Sensitive authentication metadata stored by the application

This ensures that even if a database or backup is compromised, authentication secrets remain unreadable.

3.2 What Inkrypt Does Not Replace

Inkrypt does not replace:

  • Authentication protocols (OAuth 2.0, OIDC, SAML)

  • Identity providers (IdPs)

  • Password hashing mechanisms (bcrypt, argon2, scrypt)

These controls remain the responsibility of authentication systems and identity platforms.

Result: Identity data remains protected without modifying authentication logic or flows.

4. Database & Data‑at‑Rest Encryption

Inkrypt provides fine-grained, field-level encryption at the application layer, ensuring that sensitive data is encrypted before it ever reaches the database.

4.1 Encryption Flow

Each sensitive value is encrypted using a Data Encryption Key (DEK), which is securely wrapped and managed through Inkrypt’s centralized cryptographic backend.

4.2 Key Benefits

  • Database administrators cannot read sensitive data

  • Stolen backups remain unusable

  • Cloud providers never see plaintext

  • Insider threats are significantly reduced

  • Regulatory compliance is simplified (PCI-DSS, HIPAA, GDPR)

Inkrypt enables zero-trust data storage, where access to infrastructure does not imply access to data.

5. API Payload Encryption

Modern systems rely heavily on APIs and microservices. Inkrypt enables selective encryption of sensitive API fields, supporting zero-trust architectures.

5.1 Common Use Cases

  • Encrypting PII, PCI, or PHI fields in API requests

  • Protecting data across internal microservices

  • Securing third-party integrations

  • Reducing trust assumptions between services

5.2 Example Architecture

Even if TLS is terminated at gateways or proxies, sensitive fields remain encrypted end-to-end.

6. What Inkrypt Does Not Encrypt (Explicit)

Inkrypt is intentionally scoped to application-level encryption. It does not:

  • Replace HTTPS, TLS, or mTLS

  • Encrypt disks, volumes, or block storage

  • Secure operating system memory

  • Protect against application logic flaws or vulnerabilities

  • Replace secure coding practices

This clear separation ensures that Inkrypt integrates cleanly into existing security stacks without overlap or confusion.

7. Security Philosophy & Best-Practice Alignment

Inkrypt’s approach aligns with enterprise security principles:

  • Defense in depth

  • Least privilege

  • Zero-trust data access

  • Separation of concerns

By encrypting data at its source, Inkrypt ensures that security travels with the data, regardless of infrastructure, network, or storage environment.

8. Conclusion

Inkrypt.ai fills a critical gap in modern security architectures by providing true data-centric encryption. It complements, rather than competes with, network, infrastructure, and platform security.

Organizations that adopt Inkrypt gain:

  • Stronger data confidentiality

  • Reduced breach impact

  • Improved compliance posture

  • Future-ready encryption architecture

Inkrypt protects what matters most: the data itself.