AMAZON BEDROCK / SERVICE DETAIL S05
AGENTCORE IDENTITY
CHAPTER 13 / 36
IN ONE LINE safe logins for agents
REV 2026.07
An agent often needs to act for a person: read their Google Drive, post to their Slack, check their calendar. Identity makes this safe. It gives the agent its own identity, decides who may use the agent, and securely holds the logins the agent needs, so the agent never touches a raw password.
New to these words? Read chapter 02 "Key terms" (OAuth scope, IAM, token, tool).
[ 1 ] WHAT IDENTITY IS
Identity is the login-and-permissions service for agents. Agents are not people, so they need their own kind of identity. Identity gives each agent a name of its own (a workload identity), checks every request, and keeps the keys and tokens it needs in a locked store. It works with the login systems you already use: Amazon Cognito, Okta, Microsoft Entra ID, Auth0, Google.
THE AGENT GETS
Its own identity, so it acts as itself, not by pretending to be the user.
YOU KEEP CONTROL OF
Who can call the agent, and which services it is allowed to reach.
[ 2 ] TWO DIRECTIONS, IN AND OUT
INBOUND who may use the agent
Checks the caller's login token before letting a request in.
Accepts OAuth (a login token) or AWS SigV4 (AWS identity).
Plugs into your existing login provider (Cognito, Okta, Entra, Auth0).
OUTBOUND what the agent may reach
The agent needs to call other services (Google, Slack, GitHub, your APIs).
A credential provider gets and refreshes the login for that service.
The login lives in the vault. The agent code never sees the raw secret.
[ 3 ] HOW THE AGENT GETS A LOGIN IT NEEDS
STEP 01
ASK
The agent needs to call a service, say the user's Google Drive.
==>
STEP 02
IDENTIFY
It presents its workload access token, which proves both the agent and the user.
==>
STEP 03
PROVIDER
AgentCore picks the credential provider set up for that service.
==>
STEP 04
VAULT
It fetches or refreshes the real login from the locked vault.
==>
STEP 05
CALL
The token is handed to the agent's function to call the service. The secret is never exposed.
[ 4 ] TWO WAYS TO LOG IN ELSEWHERE
AS ITSELF 2LO, machine to machine
No person involved. The agent logs in as itself.
For service-to-service work: your own backend, a shared API.
Nobody has to click "approve".
ON BEHALF OF A USER 3LO, with consent
The user is asked once to approve ("let this agent read my Drive").
For the user's own data: Google Calendar, Salesforce, Slack.
A refresh token is stored, so the user is not asked every time (about 30 days).
[ 5 ] THE VAULT, AND WHAT IT CONNECTS TO
The vault separates storing a secret from using it. The agent only ever holds a short workload access token (proving the agent and the user); with it, AgentCore fetches or refreshes the real login and uses it. The agent code never holds the long-term secret or the refresh token, and every use is logged. The vault holds OAuth tokens, OAuth client credentials, and API keys.
Logs in (inbound): Cognito, Okta, Microsoft Entra ID, Auth0. Reaches out to (outbound): Google, Microsoft, Salesforce, Atlassian, GitHub, Slack, LinkedIn, and your own APIs. Same model is used by Gateway and MCP.