August 26, 2026
Posted by Sam Gabrail
I co-hosted a live webinar with Barak Abekasis, senior solutions engineer at Akeyless, called “Securing AI Agents in Claude with Akeyless.” Agentic Runtime Authority, the Akeyless control layer we demonstrated live, is the reason I want to write this one up. Every AI agent that touches a real system needs credentials to get there, and most teams are handling that the same way they handled service accounts a decade ago: a long-lived key sitting in a config file or an environment variable, hoping nothing reads it that shouldn’t.
Akeyless started as a secrets management platform and has since expanded into certificates, identity, and, most recently, agentic runtime authority for AI agents. Barak opened with the reasoning behind that expansion: no matter what an AI agent needs to do, it needs somewhere to get the secret that lets it do it. Protecting AI agents starts with the same question every credential problem starts with: where the secret lives and who can reach it.
Watch the Demo
Akeyless Addresses Both Agent-Held Credentials and Runtime Action Risk
Akeyless addresses agentic access in two complementary stages. SecretlessAI removes credentials from the agent by brokering access through the Akeyless Gateway, eliminating the need for the agent to hold standing secrets. Runtime Authority adds an enforcement layer that evaluates the specific action an agent is attempting at runtime, including user identity, intent, permissions, and policy, before allowing it to reach the target system.
Akeyless frames this as two stages, and the split is deliberate because a team can adopt them independently.
Why Compromised Credentials Keep Showing Up in Breach Reports
Timeline showing machine identity breaches accelerating from SolarWinds through 2026, with 78% of breaches attributed to compromised non-human identities
This diagram is a timeline of publicly reported breaches, from SolarWinds through recent AI-tool incidents, tracing back to compromised identities and secrets as the top cause, and identity breaches increasingly tied to non-human identities rather than human users. Service accounts, API keys, and now AI agents outnumber people in most environments, and they are usually secured with weaker controls than the humans they act on behalf of.
AI adds a new dimension to that problem. Agents frequently need access to multiple enterprise systems that still rely on static credentials, and an agent with excessive permissions can take actions that are technically authorized but dangerous to run. A key with EC2 full access is a normal AWS permission grant. An autonomous agent holding that key and deciding on its own which instances to stop is a different risk profile entirely.
This is why identity security has to extend past storing secrets in a vault. Organizations need runtime controls that verify intent, issue temporary credentials, enforce least privilege, monitor actions as they happen, and remove standing access wherever they can.
Where Credentials Pile Up in a Typical Agent Loop
Diagram of an AI agent execution loop showing where identity is lost, prompt injection risk, standing API keys, and where enforcement is missing
The above diagram shows the agent execution loop and points out where a credential problem shows up.
The loop starts with a user request. Identity often gets lost right there, because the agent ends up acting through a shared service account instead of carrying the original user’s identity forward. That breaks attribution later, when someone needs to know who actually triggered an action.
The LLM reasoning layer can be influenced by prompt injection from emails, documents, tickets, or any other untrusted content the agent reads. If the model treats that content as instructions, the attacker does not need your credentials. They need the agent to use its own.
The agent itself is frequently where long-lived API keys and tokens accumulate, sitting in environment variables or configuration files. If the agent is compromised, everything it was holding goes with it.
Memory and RAG introduce a second version of the same risk: poisoned data can steer the agent, and sensitive information retrieved from enterprise systems can flow into the model’s context and stay there.
Traditional RBAC controls whether an identity can access a resource. It does not evaluate whether the specific action that identity is attempting right now is appropriate. And at the far end, tools, APIs, and MCP servers execute the actual work against enterprise systems, often with no central enforcement point. When something goes wrong, the audit log frequently shows only the service identity, not the user, the prompt, or the intent behind the action.
These weaknesses compound. Credential exposure can enable lateral movement; excessive authority can lead to privilege abuse and unauthorized actions; unrestricted responses can create data exfiltration; and loss of user-to-action attribution can create audit and compliance violations. Removing credentials addresses one major part of this chain, while runtime authority addresses what an authenticated agent is permitted to do.
AI Agent Security Maturity: A Typical Adoption Path
SecretlessAI and Runtime Authority are designed as stages, not an all-or-nothing platform decision. Start with SecretlessAI to remove credentials from the agent. Add Runtime Authority when the agent needs to take consequential actions, and you need action-level governance.
Stage 1: SecretlessAI™ removes the credential from the agent entirely
SecretlessAI flow: the agent requests access, Akeyless brokers the credential, and the credential expires after use
SecretlessAI™ is the first stage, and it answers one question: can an agent reach a resource without ever holding the credential that gets it there?
The Akeyless Gateway brokers access to the target without exposing the underlying credential to the agent. Where supported, Akeyless can generate short-lived, least-privilege credentials on demand; for other targets, existing credentials can remain securely managed and brokered without being exposed to the agent. The agent asks Akeyless for access, Akeyless brokers the credential against the target system, and the agent gets its result without ever seeing a password, connection string, or API key. Nothing sits in a config file, an environment variable, or the agent’s memory for an attacker to find later.
This stage is independently adoptable. A team already using Akeyless for secrets management can turn it on inside their existing Gateway and secret setup, without a separate policy engine to design first, and it closes the most common failure mode by itself: a leaked static credential.
Stage 2: Runtime Authority Evaluates What the Agent is Trying to Do
Agentic Runtime Authority diagram showing intent-aware authentication, dynamic access, and real-time checks between user intent and protected LLM outcomes
Removing the credential reduces exposure, but it does not tell you whether an autonomous action matches what the user actually wanted. This creates an important distinction: credential protection reduces the risk of credential theft, leakage, and reuse, but it does not eliminate authority risk. An agent with legitimate access can still abuse privileges, perform unauthorized actions, exfiltrate sensitive data, or create compliance violations. Runtime Authority is designed to govern these risks at the moment of action. That is what Runtime Authority adds. It works alongside any MCP-connected agent, Claude, OpenAI, Gemini, or otherwise, and it evaluates access at the moment of action rather than only at login.
The flow runs through three checks: intent-aware authentication confirms who is really behind the request, dynamic access issues a credential limited to that one action, and real-time checks evaluate the request before it reaches the target system and the response before it comes back. If either check fails policy, the action gets blocked and logged, even if the underlying credential technically had permission to do it.
Critically, the agent does not have to inherit the full authority of the human or workload behind it. Runtime policy can constrain the agent to a subset of the user’s permissions appropriate for the specific task and context.
How the Two Stages Compare
The distinction is less about feature checkboxes than the risk an agent can create: Stage 1 protects access, while Stage 2 governs the actions taken with that access.
| If your AI needs to… | Stage 1: SecretlessAI | Stage 2: Runtime Authority |
|---|---|---|
| Connect without passwords | ✓ | |
| Eliminate API keys from prompts | ✓ | |
| Use short-lived credentials | ✓ | |
| Execute production actions | ✓ | |
| Validate user intent | ✓ | |
| Enforce runtime policy | ✓ | |
| Mask sensitive responses | ✓ | |
| Stop unsafe actions mid-session | ✓ |
Customers can adopt SecretlessAI first, then add Runtime Authority when they need action-level governance.
The Demo: An AI Agent with EC2 Full Access, Run through Claude Code
Barak ran the live demo directly in Claude Code, using Akeyless’s own extension for Agentic Runtime Authority. The extension was configured with his OIDC identity, so there were no secrets stored inside Claude itself. Akeyless supports other authentication methods too, for human and non-human identities, but this demo used his own login to keep attribution tied to a real person the whole way through.
For the demo, Barak deliberately created a dynamic, just-in-time secret against his AWS account with excessive permissions, EC2 full access, specifically so the audience could see that the runtime authority policy sits above the underlying AWS permission. Having permission at the credential level is not the same as having permission at the action level, and closing that difference is exactly what Runtime Authority is built to do.
He set two categories of guardrails on the secret before running anything:
– Input policy: reject destructive or provisioning operations (terminating, deleting, or standing up new resources), and block any action against production environments entirely, before the request ever reaches AWS.
– Output policy: do not expose sensitive fields such as account ID or ARN in what comes back.
With those rules in place, he authenticated through the Akeyless extension and asked Claude to list the EC2 instances tied to the secret, including internal IPs. That request passed policy and returned the expected list.
Next, he told Claude one of the machines was stuck and asked it to restart it. Runtime Authority evaluated the request, a stop and start on a non-production instance, approved it, and Claude worked through stopping and then starting the instance. AWS itself introduces real delay here, since the platform has to validate the operation and wait for the instance to actually reach the stopped and then running state, so the pauses in the demo were AWS being AWS, not Akeyless.
While that ran, Barak switched to the Akeyless console and opened the Agentic Runtime Authority dashboard, which shows every operation the agent attempted, whether it was blocked or approved, the exact prompt behind it, and the output that came back. He also pointed out a detail he had found only that day: the Claude extension itself has a debug view that surfaces the same operation log directly inside the client, so a developer does not have to leave Claude to see why a request was rejected or approved.
He also opened the item’s temporary credentials to show that the just-in-time credential created for that action was tied to him specifically, the user who came in through Claude and asked for it. Every credential, every operation, and every prompt traces back to a real identity.
Then came the part built to fail. Barak told Claude that production was down and asked it to stop and restart one of the production servers immediately. The request hit the same input check that blocks production actions, and Runtime Authority rejected it before the command ever reached AWS. Watching it happen, I found myself thinking about infrastructure as code: you describe what you want in plain language, and since the security boundary is already enforced independently of the agent’s own judgment, the agent can act without becoming the thing standing between your intent and a safe outcome.
For the last attempt, Barak tried to talk his way around the policy directly, telling Claude he had approval from his CISO to run the operation anyway, and reminding it that the underlying dynamic secret still carried EC2 full access. Runtime Authority rejected it again. The console showed the same story as the client-side debug view: policy blocked, credential never exposed, reason logged.
Barak closed by pointing out that the same output guardrail extends to any sensitive field you want to protect, not just account IDs and ARNs. If you have a database with sensitive columns and you do not want an agent to expose them, you define the appropriate output policy, and Runtime Authority evaluates the response before sensitive information is returned to the agent or user. Enforcement therefore does not depend solely on the agent choosing to follow the instruction.
The Architecture Behind Every Request
Agentic Runtime Authority flow showing the user prompt, data request, input and permission checks, just-in-time secret access, protected data response, output check, and result returned to the user
Every request in the demo followed the same path.
- The user prompts an AI agent for a data request.
- The request routes through the customer-deployed Akeyless Gateway.
- The Gateway evaluates the request against a set of policies.
- If approved, Akeyless brokers access to the target without exposing the credential to the agent; where supported, short-lived credentials can be generated on demand..
- The activity is logged, with the requesting identity, prompt, action, and outcome captured for traceability; short-lived credentials expire according to their configured TTL..
- The Gateway evaluates the response before it returns to the agent.
The important part is that the Gateway is customer-deployed. Akeyless is not sitting in the middle of your infrastructure as a third party holding your keys. It runs inside your environment as the enforcement point you control, brokering access on your terms.
Three outcomes fall out of that architecture directly. Credentials no longer need to reside in the AI agent, its configuration, environment variables, prompts, or memory. Where the target supports dynamic credentials, Akeyless can also eliminate standing credentials by generating short-lived access on demand. Every requested action gets intent-aware enforcement against least-privilege policy, evaluated continuously across SSH, databases, Kubernetes, and cloud APIs, not just at the start of a session. And every action carries forensic traceability, logged and tied back to the exact prompt that triggered it, so an incident review does not end at a generic service account name.
Configuring Agentic Runtime Authority in Akeyless
Agentic Runtime Authority configuration steps: create an Akeyless account, deploy the Gateway, configure OIDC authentication and an access role, create a dynamic secret with guardrail policies, connect Akeyless MCP to Claude, and test a request for sensitive data
At a high level, configuration follows six steps: create an Akeyless account, deploy the Akeyless Gateway, configure an OIDC authentication method and access role, create a dynamic secret with guardrail policies, connect Akeyless MCP to Claude, and test the setup with a sensitive-data request. The example uses MySQL, but the same pattern applies when the protected target is another supported system.
This sequence keeps authentication, credential issuance, and policy enforcement outside the agent. The agent receives access through the Gateway and MCP integration, while Akeyless evaluates both the request and the response against the guardrails you define.
For a Team Running Production AI Agents
If your AI agents only ever touch read-only, low-risk resources, the credential exposure problem still applies but the blast radius is smaller. The moment an agent can restart a server, modify a database, or run infrastructure commands, the difference between “the credential technically allows this” and “this specific action should happen right now” becomes the whole security model. Static permissions answer the first question. Runtime Authority answers the second, on every request, for as long as the agent keeps running.
A practical adoption path is to start with SecretlessAI to remove credentials from the agent and secure how it reaches enterprise systems. Add Runtime Authority when the agent becomes autonomous, accesses sensitive or regulated data, operates with privileged permissions, or can write, execute, delete, provision, or otherwise change production systems. At that point, protecting the credential alone is no longer enough; the organization also needs to govern the authority exercised with that access.
Frequently Asked Questions
What is Akeyless Agentic Runtime Authority?
Agentic Runtime Authority is Akeyless’s control layer for AI agents that evaluates each requested action against identity, intent, permissions, and policy at runtime, rather than relying only on permissions established at login. It works with SecretlessAI, which brokers access without exposing target credentials to the agent.
What is the difference between SecretlessAI™ and Runtime Authority?
SecretlessAI™ removes credentials from the agent by brokering access through the Akeyless Gateway without exposing the underlying target credential. Where supported, Akeyless can generate short-lived, least-privilege credentials on demand. Runtime Authority adds intent-aware policy enforcement on top, evaluating whether a specific action matches the user’s request and blocking it in real time if it does not.
Can an AI agent bypass Runtime Authority policy by claiming special approval?
No. In the demo, the agent was told it had approval from a CISO to stop a production server despite holding EC2 full access at the credential level. Runtime Authority rejected the request because the policy evaluation runs independently of what the agent is told or how it phrases the request.
Does Akeyless Runtime Authority work with agents other than Claude?
Yes. Runtime Authority works alongside any MCP-connected AI agent, including those built on OpenAI and Gemini models, not just Claude. The demo ran in Claude Code, but the enforcement layer is not Claude-specific.
Where does the Akeyless Gateway run?
The Gateway is deployed inside the customer’s own environment. Akeyless does not sit in the middle of production traffic as a third party holding credentials; the customer controls the Gateway that brokers and enforces every request.
What happens to a credential after an AI agent uses it?
The target credential is not exposed to or stored by the AI agent. Where the target supports dynamic credentials, Akeyless can generate short-lived credentials that expire according to their configured TTL. For targets that rely on existing credentials, Akeyless securely manages and brokers access without exposing those credentials to the agent.
Can I block an AI agent from exposing specific sensitive data, like a database column?
Yes. Output policies can be written in plain language, such as an instruction not to expose account IDs, ARNs, or specific sensitive fields, and Runtime Authority enforces that boundary on the response before it reaches the agent.
How is every action traced back to the person who triggered it?
Runtime Authority ties each request to the identity that authenticated it; in the demo, an OIDC identity tied to the presenter, and logs the credential, the prompt, the action, and the outcome together in the Agentic Runtime Authority dashboard.
If you are running AI agents against production systems today, talk to Akeyless about Agentic Runtime Authority and see what the same runtime enforcement looks like against your own infrastructure.
