Zulia Shavaeva← Back to Zulia
Free AI and security guide/Learn

Learn / Identity and least privilege for agents and tools

Identity and least privilege for agents and tools

Scoping identities, tokens and permissions so agents and the tools they call can only do what they need to.

Researched on 2026-09-26 with AI assistance. Links and summaries can change; verify details with the original source. Not yet reviewed by a person.

What it is

This skill is about giving an agent and each tool it calls its own identity, then cutting the permissions attached to that identity down to the specific actions, resources and conditions the task needs. On managed platforms this is concrete work: a trust policy plus resource-scoped statements for the models, schemas, knowledge bases and Lambda functions an agent touches, with wildcards replaced by specific agent IDs once they exist.3

Cloud providers now treat an agent as a distinct principal rather than a shared service account. Google Cloud Agent Identity issues each agent a SPIFFE-based, attested identity that is not shared by multiple workloads by default, cannot be impersonated, does not allow long-lived key generation, and whose access tokens are cryptographically bound to the agent's X.509 certificates to prevent token theft.4

It also covers the authorization path between an agent and its tools. In MCP over HTTP the server acts as an OAuth 2.1 resource server: it must publish Protected Resource Metadata (RFC 9728), return WWW-Authenticate on 401, and clients must discover the authorization server and use its metadata (RFC 8414).1

Because untrusted text can hijack an agent's plan, permissions become the control that decides how far a successful injection travels, so this skill sits between AppSec and cloud IAM rather than inside either one.87

Why postings ask for it

7 of 48 postings ask for it (15%), and it concentrates in design roles: 43% of the 7 AI Security Architect postings, 19% of the 16 AI/Agent Security Engineer postings, 11% of the 9 AI Red Team postings, and none in research, GRC or consulting.P

Architect and engineer demand tracks the work CISA and international partners flag for agentic deployments: expanded attack surface, privilege creep and obscure event records, with the recommendation to avoid granting broad or unrestricted access to sensitive data or critical systems.P6

Red team interest is smaller but real, because agent tool chains fail through identity: hijacked or poorly vetted registry entries reach hosts, and attacker-controlled tool metadata then shapes host behaviour.P9

Concepts you should be able to explain

If you can say each of these out loud in two minutes, with an example, you are ready for the technical part of an interview on this skill.

Agent identity as a first-class workload identity

An agent gets its own attested credential instead of borrowing a shared service account. Google Cloud Agent Identity assigns each agent a SPIFFE ID of the form spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH, tied to the agent's lifecycle and mapped to the resource URI where it is hosted, and the same value appears in IAM allow policies as principal://. Unlike service accounts, these identities are not shared by default and do not permit long-lived keys.4

SPIFFE IDs, SVIDs and the Workload API

SPIFFE standardises three things: an identity namespace (the SPIFFE ID, a URI), a verifiable identity document (SVID, encoded as an X.509 certificate, JWT or WIT token) that can be proven authentic and proven to belong to the presenter, and a Workload API through which a workload obtains its SVIDs. The Workload API is usually exposed over a local Unix domain socket and deliberately has no authentication handshake, so the caller is attested out of band, for example by inspecting process properties.5

MCP server as an OAuth 2.1 resource server

In MCP, authorization is optional and applies at the transport level; HTTP transports should follow the spec while STDIO transports should not and instead take credentials from the environment. When used, the MCP server is the resource server, the client is the OAuth client, and the flow builds on OAuth 2.1 draft, RFC 8414, RFC 7591 and RFC 9728. Servers must expose Protected Resource Metadata listing at least one authorization server; clients must parse WWW-Authenticate on 401 to find it.1

Confused deputy in MCP proxy servers

An MCP proxy that fronts a third-party API with one static client ID, while letting MCP clients dynamically register their own client IDs, can be abused once the third-party authorization server has set a consent cookie. A crafted link with an attacker redirect URI and a new client ID skips the consent screen, and the authorization code is redirected to the attacker, who exchanges it for tokens. Mitigation is per-client consent stored server-side, keyed to client_id, plus exact redirect_uri matching, CSRF protection and clickjacking defences.2

Scoping a managed agent service role

On Amazon Bedrock Agents you replace the auto-created role with a custom one: a trust policy allowing Bedrock to assume it, plus identity-based statements only for the base models, the S3 objects holding action group OpenAPI schemas, and the knowledge bases actually attached. Statements for collaborators, provisioned throughput, guardrails, prompt management and KMS decrypt are added only if that feature is used, condition keys are recommended, and the guidance is to replace * with specific agent IDs after creation. Action group Lambda functions also need a resource-based policy allowing the role to invoke them.3

Delegated user authority versus the agent's own authority

Two different permission models sit side by side. Acting for a user means 3-legged OAuth with user consent and token management; acting on its own authority means a cloud identity for same-cloud resources, or 2-legged OAuth for machine-to-machine calls to external services, with API keys as a fallback and HTTP basic auth explicitly not recommended. In the Google Cloud design, end-user credentials are encrypted by the auth manager and decrypted at the gateway so the agent never holds the raw credential.4

Privilege as the containment boundary for prompt injection

Prompt injection exploits an agent's reliance on natural language input and is most dangerous when the agent has tool access or handles sensitive data. Rather than trying to detect every injection, design patterns constrain what the agent is allowed to do, with documented trade-offs between utility and security. That makes permission scoping, not filtering, the load-bearing control.8

Tool-call level policy and monotonic confinement

Progent expresses privilege as symbolic rules over tool names and arguments, checked deterministically on every tool call, so unnecessary calls are blocked while task-needed ones pass. Policies are generated from the user's task and updated during execution, with an SMT solver deciding whether an update narrows the policy (applied automatically) or expands it (requires explicit approval), so the effective action space can only shrink without approval. Evaluated on AgentDojo and ASB, it cut attack success rates while keeping utility, and was shown in LangChain and the OpenAI Agents SDK.7

Use fictional data and authorised sandboxes. Remove employer details and secrets from any portfolio write-up. Time estimates exclude setup. Check model and cloud costs before running tests, set spending limits, and delete lab resources afterwards.

Three exercises

In order of difficulty. Free tools. Keep what you build; it is evidence.

1Permission inventory for one agentabout 3 h

A one-page table of every tool an agent can call, the identity it uses, the resources that identity can reach, and at least three over-grants with the narrower replacement written out.34

  1. Pick one agent you can read the config for (or the Bedrock Agents service role example) and list its tools, action groups and data stores.
  2. For each entry record the principal used, the actions allowed, the resource ARNs or URLs, and any conditions.
  3. Compare against the Bedrock guidance: drop statements for features not in use, add condition keys, and replace * with specific agent IDs.
  4. Note where the agent acts for a user versus on its own authority, using the two authority models as the split.
  5. Write the three worst over-grants and the exact scoped statement you would ship instead.

Tools: text editor, spreadsheet, AWS and Google Cloud public docs

2Break and then fix authorization on a vulnerable MCP serverabout 5 h

A short write-up showing one tool abuse you achieved locally and the authorization changes that close it, mapped to specific spec requirements.1012

  1. Run Damn Vulnerable MCP Server locally and connect an MCP client.
  2. Work through the challenges that involve excessive tool permissions and credential exposure, recording each successful action.
  3. For each finding, name the missing control from the MCP authorization spec: Protected Resource Metadata, WWW-Authenticate on 401, authorization server metadata discovery.
  4. Write the confused deputy scenario for this server: static client ID plus dynamic client registration plus consent cookie, and the per-client consent fix.
  5. Re-test after applying or stubbing the fix and record what no longer works for the attacker.

Tools: Python, Damn Vulnerable MCP Server, any local MCP client

3Privilege escalation chain, then a deterministic tool allowlistabout 8 h

A demo where an agent role escalates to broader access through a chained permission, plus a rewritten policy and a call-level allowlist that blocks the chain.1173

  1. Deploy the deliberately vulnerable AWS lab that chains iam:PassRole with lambda:CreateFunction into a throwaway account that holds no production data, reproduce the escalation end to end, then destroy the stack and confirm no Lambda, role or secret is left behind.
  2. Rewrite the role so the chain fails: scope PassRole to named roles, add condition keys, and split the agent role from the execution role.
  3. In front of a small local agent, add a deterministic check on every tool call using rules over tool name and arguments, in the style of Progent.
  4. Implement narrowing updates automatically and require explicit approval for any expansion, then log both.
  5. Run one injected instruction that tries to reach a blocked tool and show the denial plus the audit record.

Tools: AWS free tier or local emulation, the iam:PassRole plus lambda:CreateFunction privilege escalation lab repo, Python, a local agent framework

Practice questions

Written from the concepts above, not collected from a named employer. Open one, answer it out loud, then tick the points you covered; the score stays in this browser.

Why is a shared service account a poor identity for an agent, and what does an agent-specific identity change?Agent identity as a first-class workload identity

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

Walk me through how an MCP client discovers where to get a token for a protected MCP server.MCP server as an OAuth 2.1 resource server

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

A team is building an MCP proxy in front of a third-party SaaS API. What identity risk do you raise first?Confused deputy in MCP proxy servers

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

How would you review the IAM role of an agent running on a managed platform?Scoping a managed agent service role

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

If you cannot reliably detect prompt injection, what do you do instead?Privilege as the containment boundary for prompt injection

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

What does monotonic confinement mean for a runtime permission policy, and why does it matter?Tool-call level policy and monotonic confinement

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

An agent needs a user's Jira tasks and also needs to write to a cloud bucket. How do you split the credentials?Delegated user authority versus the agent's own authority

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

What identity-side risks would you put in a board-level summary of an agentic AI rollout?CISA, US and International Partners Release Guide to Secure Adoption of Agentic AI

Say your answer out loud or write it down, then tick what you covered:

0 of 4 covered

Sources

Every numbered claim above links here. P = the platform's own coding of 48 job postings.

  1. MCP Authorization specification (2025-06-18) Model Context Protocol
  2. MCP Security Best Practices (confused deputy and mitigations) Model Context Protocol
  3. Create a service role for Amazon Bedrock Agents AWS
  4. Agent Identity overview (Google Cloud IAM) Google Cloud
  5. SPIFFE: Secure Production Identity Framework for Everyone (specification) SPIFFE / CNCF
  6. CISA, US and International Partners Release Guide to Secure Adoption of Agentic AI CISA
  7. Progent: Securing AI Agents with Privilege Control arXiv
  8. Design Patterns for Securing LLM Agents against Prompt Injections arXiv
  9. A First Look at the Security Issues in the Model Context Protocol Ecosystem arXiv
  10. Damn Vulnerable MCP Server Open source (community)
  11. AWS IAM privilege escalation lab: iam:PassRole plus lambda:CreateFunction Open source (community)

Resources

Free first. Levels: intro means no prior knowledge of this skill; working means you can apply it on a project; advanced means research depth or specialist tooling.

Level Format

Gaps the research could not fill with a good free source: No free, vendor-neutral hands-on lab for scoping cloud execution roles (AWS/Azure/GCP) for agents; the cloud material found is product documentation, not exercises.; No free course from a standards body (OWASP, CSA, NIST, NCSC) on agent identity and delegation; the only free structured courses found were from a cloud vendor.; Could not confirm today the IETF drafts on OAuth for AI agents acting on behalf of a user, or the token exchange and protected resource metadata RFC pages, so no primary OAuth RFC is listed.; No benchmark or CTF that scores over-privileged tool scopes specifically; the available agent benchmarks target prompt injection outcomes rather than permission boundaries.; No free, maintained open-source policy engine example for agent tool authorization (Cedar, OPA style) surfaced in searches, so the tool slots are filled by identity issuance and governance tooling.