How can organisations reduce risk from AI clients without blocking adoption?

Why This Matters for Security Teams

AI clients create risk because they behave like autonomous workloads, not like people with stable job functions. A static RBAC model assumes predictable access patterns, but agents can chain tools, retry failed actions, and request new permissions mid-task. That is why shared secrets and broad service accounts become the fastest path from convenience to exposure. Current guidance in the OWASP NHI Top 10 and the NIST Cybersecurity Framework 2.0 points toward least privilege, traceability, and rapid revocation, but agentic systems need those controls enforced at runtime, not just during onboarding.

The practical issue is that AI adoption often begins inside existing service integrations, so teams inherit tokens, API keys, and permission sets that were never designed for goal-driven behaviour. That creates a mismatch between the identity primitive and the workload. If the system cannot prove what the agent is doing, why it is doing it, and which task is in flight, then access review becomes a paper exercise. In practice, many security teams encounter agent overreach only after a tool has already been called with excessive privilege, rather than through intentional design.

How It Works in Practice

The safer model is to treat the AI client as an identity-bearing workload and to issue access only for the narrow task at hand. That means replacing long-lived secrets with short-lived, just-in-time credentials, binding the session to the agent’s workload identity, and evaluating authorisation against the specific intent of the request. For many environments, the right pattern is a mix of workload identity, policy-as-code, and revocation hooks that can stop a task when its context changes. The operational goal is not zero access. It is controlled access that can be explained after the fact.

Security teams usually start with four moves:

• Remove shared secrets from prompts, configs, and orchestration layers, then issue ephemeral secrets only when a task begins.
• Bind the client to workload identity so the platform can distinguish one agent instance from another.
• Use context-aware policy decisions for tool use, especially where an agent is asking to read, write, transfer, or deploy.
• Log intent, input, tool call, and revocation event so a reviewer can reconstruct the delegation chain.

This is aligned with the direction described in Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0, while agent-specific governance is better mapped through current work such as the OWASP NHI Top 10. In practice, that often means pairing PAM with JIT provisioning and enforcing intent-based authorisation at the policy layer rather than in the application code. These controls tend to break down when legacy integrations require reusable tokens across batch jobs, queues, and third-party connectors because the same credential then outlives the task that justified it.

Common Variations and Edge Cases

Tighter delegation often increases operational overhead, requiring organisations to balance risk reduction against latency, developer friction, and integration complexity. That tradeoff is real, especially when agents need to complete multi-step workflows across multiple systems. Best practice is evolving here, and there is no universal standard for every agentic pattern yet. Some teams can safely enforce JIT secrets per tool call, while others need a session-based model because the agent must preserve context across several steps.

Edge cases appear when the AI client has to interact with human approval gates, legacy SaaS platforms, or long-running jobs that do not fit short TTLs neatly. In those environments, the answer is usually not to restore standing privilege. Instead, it is to scope the delegation narrowly, use step-up approval for sensitive actions, and separate read-only reasoning from write-capable execution. The Ultimate Guide to NHIs — Key Challenges and Risks and the Ultimate Guide to NHIs — Why NHI Security Matters Now reinforce the point that compromise risk rises when identity, privilege, and secrets are left in a reusable state. Organisations should also be alert to the kind of fast credential abuse seen in the DeepSeek breach, where exposure can cascade quickly once secrets are embedded or left accessible.

Where the agent is allowed to take autonomous actions, security teams should assume that any reusable secret will eventually be reused in an unexpected way. That is why the strongest pattern combines ephemeral access, explicit intent checks, and revocation on completion, even if the implementation differs by platform.

Related resources from NHI Mgmt Group

• How can organisations reduce shadow AI risk without blocking adoption?
• How can organisations reduce AI agent blast radius without blocking adoption?
• How can organisations reduce shadow AI risk without slowing adoption?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?