TL;DR: Know Your Agent (KYA) shifts AI agent governance from registration-time checks to runtime authentication and authorization, tying consequential actions to a verified human owner and a cryptographic audit trail, according to 1Kosmos. The core issue is assumption collapse: traditional IAM assumes access can be validated once and remain stable, but autonomous agents decide and act at execution time.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on 1Kosmos's blog post: Know Your Agent is a runtime identity model that validates which AI agent is acting, under whose authority, and within what scope at the moment of execution.
Why it matters: It matters because agentic systems collapse registration-time governance assumptions, so IAM, PAM, and NHI teams need controls that evaluate identity and scope when actions occur, not only when credentials are issued.
By the numbers:
- A single scan of one Fortune 100 environment found 700 agents in operation across 24 MCP servers.
Context
AI agent identity is the governance problem, not just the deployment pattern. When an autonomous agent can decide what to do at runtime, a one-time registration check no longer proves who is acting, what it is allowed to do, or whether a human still stands behind the action.
Know Your Agent shifts the control point from creation time to execution time. That matters for NHI, agentic AI, and identity lifecycle governance because the effective question becomes whether identity, scope, and accountability can still be enforced when the system is selecting tools and acting at machine speed.
The article's starting position is atypical in one important way: it treats runtime identity as the control plane rather than an edge case. That makes it more useful for governance design than for product selection, because it surfaces the assumption that breaks first.
Key questions
Q: What breaks when AI agents are not governed at runtime?
A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.
Q: Why do autonomous agents increase the risk of over-privileged access?
A: Autonomous agents increase risk because they can use permissions continuously, at scale, and without human hesitation. A role that looks acceptable for a person can become dangerous when an agent can query more often, across more surfaces, and under conditions where prompt injection or tool misuse can redirect its behaviour.
Q: When should organisations require human approval for an AI agent action?
A: Require human approval when the action could change infrastructure, expose sensitive data, move laterally across systems, or trigger a business-critical workflow that is hard to reverse. Approval is also warranted when the agent’s decision depends on ambiguous input or external data that cannot be trusted at face value. High-consequence actions need a human stop point.
Q: How should teams prove that an AI agent was authorised to act?
A: Teams should prove authorisation by tying each action to a distinct agent identity, a scoped permission decision, and an audit trail that shows who approved the access and under what conditions. That evidence has to cover both the agent's evaluation history and its runtime access history, otherwise the organisation can only prove performance, not authority.
Technical breakdown
Why registration-time identity fails for autonomous agents
Registration-time identity models assume the actor's behaviour is stable enough to be approved once and reused safely. That assumption breaks for autonomous agents because the agent interprets a prompt, selects tools, and chooses execution timing at runtime. In other words, the identity decision and the action decision are no longer the same event. A credential issued days earlier cannot express the current task, target system, or risk state at the moment the agent acts. That is why static RBAC and long-lived credentials create governance blind spots for agentic systems. The relevant control point moves from onboarding to the exact moment of consequence.
Practical implication: treat runtime validation as the enforcement point for consequential agent actions, not the registration record.
How verifiable credentials and runtime authorization change the control plane
The model described in the article binds an AI agent to a verifiable credential that carries issuer identity, cryptographic binding, validity window, permitted scope, and environmental context. Runtime authorization then checks that credential before the agent can reach the target tool or system. This is materially different from a static API key or service account token, because the credential can expire quickly and can be scoped to a single action class. The governance value is auditability and blast-radius reduction: each action can be traced to the human who authorized it, the scope that was granted, and the window in which it was valid.
Practical implication: scope credentials to the specific action and enforce short validity windows for agent tasks with material business impact.
Why human approval becomes part of agent identity governance
For high-risk actions, the article places human approval in the execution path using a backchannel step-up pattern. That means the agent is not treated as a fully independent actor for every action, even if it is autonomous in planning or tool selection. The policy engine decides whether approval is required, then ties the eventual execution to a verified human owner. This is a governance model, not just an authentication pattern, because it converts accountability from a vague ownership concept into a cryptographically provable decision chain. It also explains why agent offboarding is no longer just credential revocation.
Practical implication: define which agent actions require real-time human authorization before they can reach tools or data.
Threat narrative
Attacker objective: The objective is to make an AI agent act outside its intended scope while preserving enough valid access to cause damaging business or data outcomes.
- Entry occurs when an agent receives a prompt and is allowed to operate with credentials that outlive the specific task scope.
- Escalation occurs when the agent discovers a token or permission set broader than the intended task and uses it at runtime.
- Impact occurs when the agent executes consequential actions, such as data deletion or sensitive data exposure, before governance catches up.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime identity is now the control plane for autonomous action: registration-time identity does not answer the question that matters most, which is whether the agent is allowed to do this specific thing right now. Once an agent can choose tools and timing independently, governance has to move from static access approval to execution-time verification. That changes identity from a provisioning exercise into a live control surface, and practitioners should treat that as the new baseline for agent governance.
Traditional NHI assumptions collapse when the actor is non-deterministic: service accounts and scripts are predictable enough for preassigned scope to remain meaningful, but autonomous agents are not. Least privilege was designed for actors whose intent can be approximated before execution begins. That assumption fails when the actor decides the next action at runtime, which means least privilege must be evaluated in context of the current task, not only at grant time.
Ghost agent risk is an accountability failure, not just an offboarding issue: when the human who created an agent leaves or changes role, persistent credentials can leave the agent operating without a clear owner. That creates an identity governance gap where the action chain outlives the accountable person. The practitioner conclusion is simple: ownership must be cryptographically attached to the credential, not inferred from the account record.
Know Your Agent turns agent authorization into an auditable decision chain: the combination of identity validation, scope checking, and human approval produces a record that can be reconstructed after the fact. That matters because AI agent risk is not only about blocking bad actions, but about proving which action was authorised, by whom, and under what validity window. This is the governance primitive enterprises will need as agentic workflows proliferate.
Ephemeral agent trust debt: the longer teams rely on static credentials for autonomous systems, the more they accumulate trust that cannot be re-verified at execution time. That debt shows up as opaque accountability, over-broad scope, and delayed containment when an agent misbehaves. Practitioners should treat runtime identity as the point where that debt is finally repaid or amplified.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Governance programmes built on registration-time checks will struggle as agents become more capable, because the decision to act is no longer separable from the identity that performs the action. The operational question shifts from who owns the account to whether the account can be re-verified at the moment of consequence.
Ephemeral agent trust debt: when organisations keep extending static credentials to autonomous workflows, they accumulate access that cannot be meaningfully reviewed after the fact. That creates an identity control gap where accountability, scope, and revocation all depend on the wrong time horizon.
The 53% expectation that AI may run major portions of infrastructure autonomously within three years suggests runtime identity will move from edge case to programme requirement. Teams that keep treating agent identity as a variant of service-account governance will miss the behavioural difference that drives the risk.
For practitioners
- Define execution-time approval thresholds Classify agent actions by consequence, not by tool type, and require runtime approval for data modification, money movement, infrastructure changes, and sensitive record access.
- Replace static agent secrets with short-lived credentials Issue time-bound credentials bound to a specific agent instance, human owner, and permitted scope so a single credential cannot drift across tasks or sessions.
- Attach human ownership to every agent Record who authorized the agent, who owns the work, and what action scope was granted so offboarding and revocation can follow the human, not just the software object.
- Instrument the execution path for auditability Log the agent identity, requested action, scope decision, approval outcome, and target system before the tool call completes so post-incident reconstruction is possible.
Key takeaways
- AI agents need runtime identity controls because the meaningful security decision happens at execution time, not just at creation time.
- The article's core risk is assumption collapse: static IAM models assume scope is stable long enough to approve once, but autonomous agents decide and act in the moment.
- Binding agent actions to a verified human owner and a short-lived credential changes governance from access provisioning to auditable execution control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agent identity, scope, and authority at execution time. |
| Recommendation — Apply ASI03 to validate which agent can act, within what scope, and under whose authority before execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Runtime validation replaces one-time checks that are insufficient for autonomous agents. |
| NHI-05 — Overprivileged NHI | The article highlights broad tokens and scope drift as the path to agent misuse. | |
| NHI-07 — Long-Lived Secrets | Static API keys and persistent tokens create the ghost-agent problem described in the article. | |
| Recommendation — Use NHI-04 to require execution-time authentication for agents before consequential actions proceed. Use NHI-05 to constrain agent permissions to the minimum scope needed for each task. Use NHI-07 to replace persistent agent secrets with short-lived, task-bound credentials. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The incidents described show agents using broader credentials to reach and affect unintended systems. |
| Recommendation — Map agent misuse to TA0006 and TA0008 to hunt for broad credentials used outside intended scope. | ||
Key terms
- Know Your Agent: A governance pattern for verifying that an AI agent is the intended actor, not a hijacked or impersonating one. It extends identity assurance beyond login by focusing on runtime behaviour, delegated authority, and the integrity of the agent's actions across connected systems.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Verifiable Digital Credential: A verifiable digital credential is structured identity data that can be checked cryptographically by a relying party. Instead of relying on visual inspection, the verifier validates issuer signatures and presentation rules, which gives the control a clearer trust basis than an image-based document.
- Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight, the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org