Securing AI Agents and Machine Identities

What you will learn

• Map the trust domains in an agent and tool workflow.
• Constrain delegated authority to a task, resource, and time window.
• Evaluate sensitive tool intent at an enforceable decision boundary.

Agents create a new access pattern

An AI agent may act through an orchestration runtime, call tools and APIs, read data stores, and invoke external services. The user, agent, runtime, tool, and target resource can all belong to different trust domains. A single login check cannot express the authority of every action in that chain.

Treat agents as workload identities with explicit ownership, credential lifecycle, scope, and audit. Where workload attestation is available, use it as evidence about the runtime. Do not assume every agent platform exposes attestation or that identity alone proves safe behavior.

Constrain delegated authority

A human may delegate a bounded task to an agent, but the agent should not inherit unrestricted authority simply because the user is privileged. Represent the delegation, allowed resources, operation types, data sensitivity, and expiration in policy or a token scope that the enforcement layer can actually honor.

Prefer short-lived, task-specific grants. Separate read from write, constrain bulk export, and limit access to the minimum resource set. Re-evaluate when the agent changes task, requests a more sensitive tool, or the context changes materially.

Inspect intent at the action boundary

A sensitive action should pass through a policy decision point before the tool executes it. Evaluate agent identity, delegated authorization, requested tool and parameters, workload context where available, data sensitivity, risk signals, and relevant telemetry.

For example, an agent with a valid identity may request an export that exceeds the task’s authorized scope. The decision can deny the request or route it for human approval. The tool gateway or API permission layer must enforce that outcome; a diagram alone cannot block the call.

Reassess during the workflow

Agent workflows are sequences of actions, not a single access event. Re-check authority before consequential tool calls, after a step changes the data or risk context, and when a grant expires. Keep evaluation proportionate so low-impact steps remain efficient while sensitive operations receive stronger controls.

Log the request, policy inputs, decision, approval, tool response, and output reference. Avoid logging secrets or unnecessary sensitive content. This trace helps teams understand what the agent attempted and whether the enforcement point applied the decision.

Build a controlled agent pilot

Inventory agent identities and tool permissions. Start with observe-only intent analysis, then simulate deny and escalation policies against realistic requests. Enable enforcement for a narrow tool and a reversible action before extending to higher-impact operations.

Measure blocked overreach, approval burden, false positives, permission lifetime, and audit completeness. The core design is a policy decision boundary around tool use, backed by enforceable delegated authority and repeated evaluation—not a claim that an agent’s identity certifies its behavior.

Separate the agent, user, and workload identities

An agent may act for a person, run as a workload, and call a tool with its own service identity. Preserve those identities separately in the request and audit record. A human's successful sign-in does not mean the agent should inherit every permission of that person, and a valid service credential does not prove that the current action belongs to an approved task. Define the delegation relationship, audience, permitted resources, expiry, and revocation path explicitly.

Prefer short-lived credentials and scoped tokens over long-lived shared secrets. Bind a delegated grant to the task and tool where the platform supports it, and avoid putting credentials in prompts, retrieved documents, model context, or tool output. If a workflow must retain authority across several steps, renew it through a policy-controlled mechanism and record which actor or service authorized the renewal.

Enforce intent at the tool boundary

Place a policy gateway between the model's proposed call and the tool that performs it. Validate the tool name, operation, arguments, target resource, quantity, and data classification against a structured schema. A natural-language description such as summarize the account is not enough when the actual arguments request every customer record. Apply limits to result size, write scope, export destinations, and chained calls, then require explicit approval for actions whose impact exceeds the delegated task.

Treat tool results and retrieved material as untrusted data. A document can contain instructions that attempt to redirect the agent, but those instructions must not alter the task grant or disable the gateway. Keep the model from directly reaching sensitive APIs around the enforcement point, and reject calls when policy cannot be reached rather than silently granting the request.

Test the whole agent workflow, not just its prompt

Create scenarios for normal completion, prompt injection, excessive reads, destructive writes, confused-deputy access, duplicated tool calls, expired credentials, and an interrupted workflow. Check whether policy denies the unsafe step while allowing unrelated safe work to continue. Inspect the exact structured request and downstream response; a favorable model explanation is not evidence that the system enforced the intended limit.

Track denied and approved calls by tool and risk class, unexpected scope expansions, human overrides, policy-service failures, and data returned to the model. Keep enough trace context to reconstruct decisions without retaining sensitive prompt contents longer than necessary. Assign an owner to review new tools and permission changes before they enter the agent's reachable environment.

Review outputs and containment as separate controls

A tool gateway can block an unauthorized write while the agent still returns sensitive information in its answer. Test both the action path and the output path: restrict which records the tool can retrieve, limit the fields returned, and verify that the model cannot disclose data outside the user's and task's scope. Treat generated summaries as derived data with the same classification and sharing rules as the material they summarize.

Exercise a gateway outage, expired delegation, and emergency credential revocation. Confirm that the agent cannot call a protected service directly when the policy boundary is unavailable, and that an operator can identify active sessions and terminate them. Review traces for task identity, requested operation, policy result, and tool status while minimizing retention of private prompts. These checks validate the system boundary, not just the language model's refusal behavior.

Worked example

A support agent is asked to summarize a ticket, but a prompt injection inside the ticket requests a bulk export of customer records.

1. Bind the agent's runtime identity to the approved support task and narrow its delegated data scope.
2. Treat ticket content as untrusted input and require the policy gateway to authorize each proposed tool call.
3. Deny the export, preserve the permitted summary action, and log the policy reason and tool response.

Expected outcome: The agent can complete its bounded task without gaining authority from instructions embedded in the data it reads.

Further reading

• NIST AI 600-1: Generative AI Risk Management Profile
• OWASP Top 10 for Agentic Applications

Knowledge check

An authenticated agent requests a bulk export beyond its delegated task. Which controls should decide and enforce the outcome?