Refael Angel, Co-Founder and CTO of Akeyless – Interview Series

Refael Angel, Co-Founder and CTO of Akeyless, is a cybersecurity and software engineering leader with deep experience in cloud security, encryption, machine authentication, and enterprise infrastructure. Since co-founding Akeyless in 2018, he has helped build the company around modern secrets management and identity security for cloud-native environments. Before Akeyless, he worked as a Senior Software Engineer in Security at Intuit, where he built systems for public-cloud encryption key management and machine authentication, gaining hands-on experience across AWS, Go, Python, Java, PHP, Bash, Linux, Git, and Jenkins. Earlier in his career, Angel held software engineering roles at 3D Systems and Cimatron, developing CAD/CAM and Windows-based applications using C/C++, C#, WPF, MFC, and object-oriented design patterns.

Akeyless is an identity security company focused on securing machines, AI agents, and humans through a cloud-native platform built around zero-knowledge cryptography. Its platform brings together secrets management, encryption key management, certificate lifecycle management, privileged access, and machine identity security, giving organizations a unified way to manage credentials, keys, certificates, and access across hybrid, multi-cloud, DevOps, and AI environments. The company’s positioning reflects a broader shift in cybersecurity: as workloads, services, and AI agents increasingly perform system access without direct human involvement, enterprises need stronger controls around non-human identities, short-lived credentials, automated rotation, and runtime governance.

You co-founded Akeyless in 2018 after building encryption key management and machine authentication systems at Intuit. What gap in cloud security and identity management convinced you that it was time to start Akeyless, and how has that original vision evolved as AI agents have emerged as a new class of digital identities?

At Intuit, I was part of the team building encryption key management and machine authentication systems at a time when Intuit was one of the earliest large enterprises to move to the cloud. What became clear to me was that every organization adopting the cloud would eventually face the same problem we were solving internally: how to manage secrets and keys across distributed, dynamic infrastructure. Building this in-house consumes enormous engineering resources, and it makes no sense for every company to reinvent it. The logical answer was a SaaS model.

The catch was trust. This is the most sensitive material an enterprise owns, and no serious organization will hand a third party the ability to access it. So the requirement was almost contradictory: deliver it as SaaS for scale and simplicity, yet make it architecturally impossible for the vendor to ever see the customer’s data. That tension is exactly what gave birth to Distributed Fragments Cryptography (DFC). DFC lets us run a fully managed SaaS control plane while the customer holds a fragment that we never possess, so we are mathematically unable to access their keys. That became the foundation of the SaaS plus Zero-Knowledge model that Akeyless is built on.

The original vision was about securing human and machine access in the cloud. AI agents are the natural and most extreme extension of that same problem. They are non-human identities operating at a scale and speed no directory was designed for, and the same Zero-Knowledge, identity-centric foundation now extends directly to them.

You are credited as the architect behind Akeyless’ patented Zero-Trust encryption technology. What were the biggest technical challenges in building a security model that could eliminate trust assumptions while remaining practical for large enterprises?

The hardest part was making “trust no one” practical rather than academic. Most split-key or secret-sharing schemes still assemble the full key at some moment, usually inside a single process, HSM, or enclave at the instant of a cryptographic operation. That brief window is precisely what attackers, malicious insiders, and legal-compulsion scenarios target.

With DFC the key is never assembled, not at creation, not at rest, and not during use. Fragments are generated independently in separate trust domains, and cryptographic operations run as a distributed computation where each fragment holder computes its share locally and only partial results are exchanged. The engineering challenge was achieving this with the latency, throughput, and reliability that large enterprises demand in production.

A second challenge, and one of the most significant, was enabling continuous refresh of the fragments. We had to be able to replace every fragment with a new mathematical value, in every location, while the underlying master key the fragments represent stays unchanged and the cryptographic process is never disrupted. This added a very substantial layer of security to the solution. Because of refresh, an attacker can no longer collect fragments patiently over time. A fragment captured last week is mathematically unrelated to the fragments that exist today, so it is noise rather than a head start. To learn anything about a key, an adversary would have to compromise every fragment location simultaneously, within a single refresh window, and that requirement grows exponentially harder as locations, trust domains, and refresh frequency increase. Combined with the all-or-nothing threshold, where 100 percent of fragments are needed to reveal anything and any strict subset leaks zero information, refresh turns the security model from a static guarantee into a time-bound one.

Many organizations are racing to deploy AI agents, yet identity security often remains an afterthought. What are the most common mistakes companies make when giving AI agents access to enterprise systems and sensitive data?

The biggest mistake is treating an agent like a service account and handing it a static, long-lived API key. That credential becomes a permanent, harvestable asset sitting inside a non-deterministic, prompt-injectable actor.

The other common errors I see: granting standing privileges instead of just-in-time access, relying on coarse role-based permissions that describe what an agent can reach but never what it intends to do, giving agents direct network paths to databases and APIs so a compromise becomes lateral movement, and having no audit chain that ties an agent action back to the human and prompt that triggered it. Each of these is an attempt to retrofit human-era controls onto something that does not behave like a human.

Akeyless has argued that AI agents require a fundamentally different identity model than humans or traditional machine workloads. What makes AI agents uniquely difficult to secure compared to existing IAM and PAM frameworks?

The core mistake is treating AI agents as a new kind of user, or even a new kind of service account, and assuming they can be onboarded and governed like human identities. That is a category error, for a few connected reasons.

Agent identities are not enumerable. The specific instance you want to govern usually does not exist yet, and by the time it does, it is already gone. An agent can spin up on a Lambda, run for 800 milliseconds, and vanish before any scanner notices it, or spawn chains of sub-agents across VMs, containers, and serverless that complete in seconds. Registering these in a directory is treating ghosts as residents: by the time the entry commits, the entity it described is gone.

The right anchor is therefore not the agent but the workload identity its runtime already issues, the AWS execution role, the Kubernetes service account token, the SPIFFE SVID. That identity already exists, is vouched for by the platform the agent runs on, and disappears when the agent does. Because the identities are ephemeral, the only stable entities to write policy between are the auth methods and the target systems, not named identities and scopes.

And this is where existing IAM and PAM break most decisively: static RBAC and ABAC cannot contain a non-deterministic actor. An agent with a perfectly scoped token and a perfectly enforced TTL can still be prompt-injected, hallucinate a destructive query, or pivot from a read task to a write task in the same session, with no policy violation visible at the authorization layer. RBAC and ABAC evaluate at authentication, not after, because what happens after is decided by an LLM looking at a context window the policy author cannot see.

So agents are uniquely difficult because they are ephemeral, non-deterministic, multi-substrate, and prompt-injectable all at once. The missing layer is not a better directory. It is intent-aware enforcement on every action, mediated by a gateway that checks what the agent is actually doing against what it said it would do, before any credential is minted.

There is growing discussion around “secretless” architectures for AI systems. How do you define secretless authentication, and why do you believe static credentials and API keys are becoming unsustainable in the age of autonomous agents?

Secretless authentication means the agent never holds a credential at all. Instead of giving the agent a key it must store and present, the agent authenticates through its native workload identity, and a short-lived, just-in-time credential is injected into a brokered session at the moment of execution, then destroyed when the session ends. The agent never sees it.

Static credentials and API keys are becoming unsustainable for a simple reason: a secret an agent holds is a secret an attacker can steal. In a world where the actor holding the credential can be prompt-injected or hallucinate, a long-lived key turns every compromised agent into a key leak. Remove the credential from the agent and a compromised agent has nothing to leak. That is the whole point of what we call SecretlessAI.

As AI agents gain the ability to plan, execute actions, and interact with multiple systems independently, what new attack vectors concern you the most over the next three to five years?

The vectors that concern me most all stem from agents being able to plan and act across systems independently. Prompt injection that hijacks an agent’s intent mid-task is the clearest one, because the identity remains valid even as the behavior turns malicious. Beyond that, I worry about agent-to-agent handoffs where authority is passed along a chain with no clear accountability, lateral movement through agents that have direct network reachability, and data exfiltration where an over-permissioned agent pulls far more than its task requires.

The common thread is that the credential and the role can be perfectly legitimate while the action is not. Defenses that only check permission, not purpose, will not catch any of these. That is why intent-aware enforcement at a gateway, on every single action, is the control I believe will matter most.

We are seeing a shift from securing human identities to securing machine and agent identities. How do you see the balance of security priorities changing as organizations begin managing millions of non-human identities across their infrastructure?

We are moving into a world where the overwhelming majority of system access is performed by non-human identities, machines, workloads, and now agents, yet most tooling still assumes a human behind the keyboard. The result is secrets everywhere, standing privileges, and identities no one can fully track.

The shift in priorities is from periodic, human-paced controls toward continuous, runtime enforcement at machine scale. When you manage millions of non-human identities, you cannot rely on enrollment, certification campaigns, and quarterly access reviews. You need ephemeral-by-construction identity, zero standing privilege, and policy evaluated automatically on every action. Human identity security does not go away, but it becomes a smaller fraction of the surface, and the architecture has to be built for the non-human majority first.

Recent research suggests that AI agents may already be accessing information beyond their intended permissions. What governance and runtime controls should organizations have in place before allowing agents to operate autonomously in production environments?

Before any agent operates autonomously in production, I would want a few things in place. First, no standing credentials on the agent, with just-in-time, short-lived access injected per session. Second, no direct network path, so every agent action is brokered through a mandatory choke point rather than reaching databases and APIs directly. Third, intent-aware policy enforcement that evaluates the purpose of a request against its originating prompt before any credential is minted, so an agent asked to analyze revenue cannot issue a destructive command. Fourth, in-session inspection and response masking so sensitive data like PII and PHI is redacted before it enters the agent’s context window. And fifth, a single immutable audit record linking the human prompt, the classified intent, the policy verdict, the session, and the final action.

Discovery and visibility matter too, but as inputs to policy, not as a prerequisite for protection. You should be able to govern an agent the first time it authenticates, even if you have never seen that specific instance before.

The industry often focuses on model safety, but less attention is given to identity, authorization, and access control. Why do you believe these areas will become some of the most important security challenges of the AI era?

Model safety gets the headlines, but a perfectly aligned model still has to act in the real world, and the moment it acts it needs access to systems and data. That access is where the actual damage happens. A model that never touches a database cannot exfiltrate one. The risk materializes at the authorization boundary.

Authorization is also the hardest part of agentic security, because the actor is non-deterministic and ephemeral. You cannot solve it purely at the model layer, and you cannot solve it with static roles. It requires continuous, intent-aware enforcement on every action. That is unglamorous infrastructure work, which is exactly why it is under-discussed and exactly why it will turn out to be one of the most consequential security problems of this era.

Looking ahead, do you believe enterprises will eventually require a dedicated identity layer for AI agents, similar to how identity providers became essential for human users, and what would that future architecture look like?

Yes, but it will not look like the human identity provider model simply rebranded for agents. Trying to build a directory of agents is building a directory for ghosts, identities that are gone before you finish enrolling them.

The agent identity layer I expect will anchor identity to the workload that the runtime issues, cloud IAM, Kubernetes service accounts, OIDC federation, and standards like SPIFFE/SPIRE that are already production-proven and cross-substrate. Authorization will be expressed as relationships between auth methods and target systems rather than between named identities and scopes. And the center of gravity will be a runtime enforcement plane, a gateway that brokers every action, classifies intent, injects ephemeral credentials, masks sensitive responses, and produces a full forensic chain. Identity still matters, but it falls into place behind enforcement rather than in front of it. That runtime authority layer, sitting on the same platform that already governs human and machine access, is what I believe every enterprise running agents in production will end up needing.

Thank you for the great interview, readers who wish to learn more should visit Akeyless.