Short answers. Links to the longer version.
Does an AI agent create its own identity when it acts on my behalf?
No. When a browser-use or computer-use agent acts on your behalf, it borrows your credentials - your session cookie, your OAuth token, your authenticated context. The downstream system sees you, not the agent. If something goes wrong, the audit trail shows your credentials on every action.
Read: The NIST IAL/AAL Crosswalk →
What are IAL and AAL, and why do they matter for agent deployments?
IAL (Identity Assurance Level) measures how well a person's real-world identity was verified at enrollment. AAL (Authentication Assurance Level) measures how strongly a person proved they were that identity at login. Both are set by the system being accessed, not the agent deployer. They define the trust bar your agent is acting inside of.
Read: The NIST IAL/AAL Crosswalk →
Can an agent satisfy AAL2 by passing through an MFA code?
Technically yes. Practically no. AAL2 is intended to prove a human is in control at login. An agent intercepting an OTP or push notification defeats that intent - it proves only that someone has access to those credentials, not that a human is present and consenting. NIST marks SMS OTP as RESTRICTED. An agent reading SMS codes is a second-order version of that same attack surface.
Read: The NIST IAL/AAL Crosswalk →
What is prompt injection and why is it especially dangerous for browser-use agents?
Prompt injection is when content on a web page contains instructions that redirect the agent's behavior - invisible text, DOM manipulation, adversarial form pre-population. For government sites, the attack surface includes third-party analytics scripts, CMS plugins, and form libraries, any of which can inject instructions the agent treats as legitimate. The mitigations are real but imperfect: the research community hasn't solved it.
Read: AI Agent Session Security →
Why doesn't a dry run fully predict what happens in production?
CSRF tokens expire between sessions. Authenticated pages aren't in sitemaps. Dynamic content changes. Session state dependencies may not replicate. The dry run validates the plan; it can't fully validate the execution. Form structure fingerprinting and staged step-by-step execution get you closer than screenshots.
Read: AI Agent Session Security →
How can a system tell when an agent is acting instead of a human?
Mostly it can't - which is the problem. The better model is disclosure with incentive: build a mechanism where declaring agent identity unlocks smoother access (appropriate rate limits, cleaner audit trail), and where undeclared agent sessions face additional friction. Legitimate teams deploying agents will disclose when it helps them.
Read: Building AI Agent-Aware Systems →
What should a token carry to make agent access legible to downstream systems?
Agent identity and responsible party. The human principal and their IAL/AAL at authorization. Declared scope - which endpoints, which action types. The delegation chain if sub-agents are involved (scope should only narrow at each hop). An authorization timestamp and expiry. The OAuth ecosystem already has most of the primitives via JWT custom claims.
Read: Building AI Agent-Aware Systems →
What standards work is happening on agent identity right now?
Three efforts worth following: WIMSE (IETF, workload identity for distributed systems with agents in scope), Transaction Tokens for Agents (IETF draft extending OAuth to carry agent context with scope-narrowing enforcement at each hop), and HDP - Human Delegation Provenance (cryptographic chain of custody from authorizing human to every downstream action, verifiable offline). None are accepted RFCs yet.
Read: The NIST IAL/AAL Crosswalk →