Why do AI agents complicate digital trust programmes?

Why This Matters for Security Teams

AI agents complicate digital trust because the trust boundary shifts from login time to runtime. A signed-in agent can still choose different tools, chain requests, or follow a prompt that was not anticipated when access was granted. That makes classic identity controls necessary but insufficient. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to runtime governance, not just pre-issued trust.

For NHI Management Group, the practical issue is that agents behave more like dynamic workloads than fixed users. That means digital trust programmes must track scope, tool access, data handling, and revocation with the same seriousness as authentication. The lesson is visible in NHIMG research such as Top 10 NHI Issues and OWASP NHI Top 10, which show how quickly weak lifecycle controls become operational risk. In practice, many security teams encounter agent misuse only after an agent has already accessed the wrong tool or data, rather than through intentional design review.

How It Works in Practice

Effective digital trust for agents starts with workload identity, then adds runtime policy enforcement. The identity primitive is not a human user record but a cryptographic workload identity that proves what the agent is and what system context it is operating in. Many teams use short-lived OIDC-based tokens or SPIFFE-aligned workload identities, then bind those identities to policy decisions made at request time.

This is where static RBAC often fails. A role can say an agent may use a database, but it cannot express whether the agent may use that database for this task, with this dataset, through this tool chain, at this time. Better patterns rely on intent-based or context-aware authorisation, where policy evaluates the agent’s goal, input provenance, execution environment, and downstream impact before issuing permission.

• Issue just-in-time credentials per task, not long-lived secrets that remain usable after the job ends.
• Restrict each agent to the smallest tool set needed for the current workflow.
• Re-evaluate permissions at runtime with policy-as-code rather than assuming prior approval is still valid.
• Revoke tokens automatically on completion, anomaly detection, or task failure.

The operational goal is to make trust ephemeral, contextual, and revocable. That aligns with the control logic behind CSA MAESTRO agentic AI threat modeling framework and the broader governance approach in Lifecycle Processes for Managing NHIs. These controls tend to break down when an agent spans multiple vendors, because identity context and revocation signals do not propagate cleanly across disconnected tool chains.

Common Variations and Edge Cases

Tighter runtime control often increases orchestration overhead, requiring organisations to balance faster agent execution against stronger containment. There is no universal standard for this yet, so current guidance suggests starting with higher-risk agents first: those that can move money, modify production systems, or access sensitive secrets.

Edge cases usually appear when agents are embedded in multi-agent pipelines, delegated workflows, or long-running automation. In those environments, one agent may inherit context from another, which makes simple allowlists too coarse and simple deny rules too brittle. A good programme separates identity, authorisation, and audit so that each handoff is visible and reversible.

Another common gap is offboarding. If an agent is retired but its tokens, tool grants, or connector permissions remain active, the digital trust model is already broken. NHIMG research on LLMjacking shows how quickly exposed credentials can be abused, while the State of Secrets in AppSec highlights broader secrets-management fragility. Best practice is evolving toward short-lived secrets, automated revocation, and policy checks that treat agent behaviour as dynamic rather than presumed safe by default.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents complicate zero trust and least privilege programmes?
• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?