Add Agent Sign-In with AgentID

Add AgentID sign-in to a web app and track actions by agent identity.

Introduction

30 Second Summary

When a person and their software share one login, every action appears to come from the same account. Your app cannot tell who actually did what.

In this project, you will add AgentID sign-in to a small web app using OpenID Connect. The finished app displays the agent beside its owner while recording the agent's actions under its own identity.

What You'll Build

After you sign in through AgentID, the app shows the agent beside its owner while attributing a recorded action to the agent.

By the end of this project, you'll have:

An AgentID sign-in button that sends an agent through a standard login flow for your app.
A profile page that shows the agent's own identity plus the human who owns it.
An activity log that tags an action with the agent instead of the human.
Secret Mission: An optional challenge that extends your agent-aware identity skills.

Are there any prerequisites?

You'll need Node.js on your computer plus basic familiarity with editing a small web app. The project guides you through the AgentID connection and login flow.

Before We Start

Your AgentID app eventually passes sign-in through a browser. A local server then handles the result.

This step prepares Visual Studio Code for the files you build later.

You also confirm that Node.js responds in your terminal. A second check confirms npm.

In this step, get ready to:

Confirm that a modern browser opens successfully.
Prepare Visual Studio Code for editing project files.
Install Node.js with its bundled npm package manager.

Check your local toolkit

Your browser handles the sign-in redirect. Visual Studio Code gives you a place to edit the local app.

Launch a modern browser from your Dock, taskbar, or application menu.
Visit the official Node.js download page to confirm that the browser can reach the internet.

You should see download options for your computer. This confirms that your browser is ready for the sign-in flow later.

Press Cmd+Space on macOS or the Windows key on Windows to open application search.
Type Visual Studio Code into the search bar.

✔️ Visual Studio Code appears

Select Visual Studio Code from the search results.

Your editor is ready. You now have a workspace for the app files you create later.

ⓧ Visual Studio Code is missing

The missing search result means you need to install the editor before creating the app.

Open the official Visual Studio Code download page.
Download the installer for your operating system.
Run the downloaded installer.
Complete the installer prompts using the default options.
Return to your operating system's application search.
Search for Visual Studio Code.
Select Visual Studio Code from the search results.

You should see the editor window. That confirms the installation worked.

Return to your operating system's application search.
Search for your computer's terminal application.
Select the terminal application from the search results.

You should see a terminal prompt where you can enter commands. Keep this terminal open for the next check.

Install Node.js if needed

Node.js runs JavaScript outside the browser. Its installer also provides npm for managing the packages your app needs.

Check whether Node.js is already available by running this command:

node -v

What Does This Command Do?

This command asks Node.js to print its installed version. A version number confirms that your terminal can find the runtime.

✔️ I see a version number

Good news. Node.js is already installed and responding to terminal commands.

ⓧ Command not found

The missing command means Node.js is unavailable in your terminal. The official installer adds Node.js with npm.

Return to the official Node.js download page.
Select the LTS release for your operating system.
Download the installer.
Run the downloaded installer.
Complete the installer prompts using the default options.
Close your terminal after the installation finishes.
Reopen your terminal from application search.
Check Node.js again by running this command:

node -v

What Does This Command Do?

This command checks the new installation from a fresh terminal session. You should now see a Node.js version number.

Still Missing Node.js?

Close every terminal window before opening a fresh one. An existing terminal may still use the system settings from before the installation.

Run the official installer again if the command remains unavailable. Confirm that the installer completes before reopening the terminal.

Ask for help: Node.js is installed, but my terminal cannot find it. Can you help me check my setup?

Verify npm and finish the check

npm arrives with Node.js. Its own version check confirms that the package manager is ready for your app dependencies.

Before you check, do you expect npm to report its own version now that Node.js is ready?

Verify npm by running this command:

npm -v

What Does This Command Do?

This command asks npm to print its installed version. A version number confirms that the package manager is available from your terminal.

You should see an npm version number beneath the Node.js check. That completes your local toolchain setup.

No npm Version Number?

Close the terminal before opening a fresh session. This reloads the system settings created by the Node.js installer.

Run the Node.js installer again if npm remains unavailable. The installer should provide both tools.

Ask for help: Node.js works, but npm does not return a version number. Can you help me fix it?

Your browser, editor, terminal, Node.js runtime, and npm package manager are ready. Next, you'll create your AgentID account and give your test agent its own identity.

Create an Agent Identity

When an agent uses your personal login, every action appears to come from you. Your app needs a separate identity for the agent.

AgentID gives the agent its own email identity through OpenID Connect. It also connects that identity to you as the human owner.

Why give the agent its own identity?

A shared human login records the agent's actions under your identity. A separate agent email gives your app a distinct actor.

The linked owner preserves accountability. Your app can identify the agent without losing the human relationship behind it.

In this step, get ready to:

Create your AgentID console account.
Create a practice agent identity with an AgentID-issued email address.
Verify the identity details in the console.

Sign up for AgentID

The console account represents the human side of this relationship. AgentID uses it to associate you with the identities you manage.

Account setup can feel sensitive because it uses your personal login. That login remains separate from the practice agent identity.

Visit the official AgentID console in your browser.
Click Sign in on the landing page.

You'll move to the authentication page for your AgentID account.

Choose the sign-up path on the authentication page.
Complete the account form with your own details.

The authentication page now has the details it needs to establish you as the account owner.

Complete the verification step presented by the authentication page.
Return to the AgentID console after verification.

You should see the signed-in AgentID console. Good work. Your human-owner account is ready for the identity you create next.

Can't reach the signed-in console?

Check that you completed every account verification prompt before returning to the console.
Retry the flow in a regular browser window if authentication keeps returning to the starting page.

Ask for help: Help me troubleshoot an AgentID console sign-in flow that does not reach the signed-in console.

Create the practice agent

The practice agent needs an identity that belongs to the agent itself. Its issued email becomes the address your app recognizes during sign-in.

Locate the area for managing agent identities in the signed-in console.
Start a new agent identity from that area.

You'll see a form that asks how the new identity should appear.

Enter NextWork Practice Agent as the display name.
Keep your signed-in account selected if the form presents a human-owner choice.

The form should now pair the practice agent name with your owner account.

Submit the identity form to create the practice agent.

You should land on the new identity's details. That is the key separation in place. The agent now has an identity of its own.

Record the issued agent email here: your AgentID-issued agent email.
Confirm the listed human owner matches your signed-in account.

Can't create the identity?

Confirm that you are using the signed-in AgentID console from the previous substep.
Check the form for an incomplete required field if submission does not continue.
Use a different practice display name if the console reports that your chosen name is unavailable.

Ask for help: Help me identify why the AgentID console will not create my practice agent identity.

Verify identity and ownership

The final check proves that the agent and owner are represented separately. This is the identity model your app uses in the later sign-in flow.

Before you check, which email do you expect the console to treat as the agent's identity?

Select the practice agent in the AgentID console.
Confirm the displayed name is NextWork Practice Agent.
Confirm the displayed agent email matches your AgentID-issued agent email.
Confirm the human owner matches your signed-in account.

You should see NextWork Practice Agent paired with your AgentID-issued agent email.

The ownership details should identify your account as the human behind the agent. You now have a separate agent identity with a clear line of accountability.

Redact your personal owner email before capturing a screenshot.
Leave the practice agent's name visible in the screenshot.
Leave the AgentID-issued agent email visible in the screenshot.

Identity details look wrong?

Return to the identity list if you selected a different agent.
Check that the recorded agent email matches the address shown on the identity details page.
Confirm that the active console account belongs to the intended human owner.

Ask for help: Help me verify the agent email and human owner shown for my AgentID identity.

Your practice agent now has its own email identity with you linked as its human owner. Next up, you'll scaffold the local web app that accepts this identity.

Register Your Web App

Your practice agent already has an AgentID email identity linked to you as its owner. Your web app now needs an OpenID Connect client registration before AgentID can return a signed-in agent to it.

An Express scaffold gives you a local app that can receive the redirect. AgentID then assigns that app a client ID with an approved callback address.

In this step, get ready to:

Scaffold a local Express web app.
Run the app in your browser.
Register the app as an AgentID client.

Prepare the project workspace

The Express generator creates the routes and views that make up a small web app. This gives the next step a working foundation for the login flow.

Move to your Desktop in the terminal by running this command:

cd ~/Desktop

What does this command do?

This changes the terminal location to your Desktop. The generated app folder will be easy to find there.

The first npx run may pause for permission to download the generator. That prompt is expected.

Generate a Pug-based Express app by running this command:

npx express-generator --view=pug myapp

What does this command do?

The generator creates a myapp folder containing a Node.js web application.
The --view=pug option adds templates that Express can render as web pages.

You should see a list of generated paths. The list includes package.json, app.js, routes, and views.

Move into the generated myapp folder by running this command:

cd myapp

What does this command do?

This moves the terminal into the folder containing your app. The next commands now apply to myapp.

Install the generated app's dependencies by running this command:

npm install

What does this command do?

This reads package.json and downloads the packages required by the scaffold. The app can run once the installation completes.

The terminal should finish without a dependency installation failure. Your local web app is now scaffolded.

Having trouble scaffolding the app?

Confirm that your terminal is on the Desktop before generating myapp.
Remove an older myapp folder if the generator reports that the destination already contains files.
Check your internet connection if the generator or dependency download cannot reach the package registry.

Ask for help: Help me diagnose why my Express scaffold or npm installation failed.

Run the scaffolded app

Running the scaffold proves that Node.js can serve the generated project. The server keeps this terminal busy until you stop it with Ctrl+C.

Start the generated web app by running this command:

npm start

What does this command do?

This runs the start script defined by the generated package.json. Express begins listening for browser requests on your computer.

Switch back to the browser from earlier.
Enter http://localhost:3000/ in the address bar.
Press Enter.

You should see the generated Express welcome page. This proves that the scaffold can serve a local web page.

Can't see the welcome page?

Confirm that npm start is still running in the terminal.
Check that the browser address uses port 3000.
Return to the myapp folder if the terminal reports that it cannot find the start script.

Ask for help: Help me find out why my generated Express app is not loading locally.

Good work. Your local app can now receive browser requests.

Return to the terminal running the server.
Press Ctrl+C to stop the server.

Register the OIDC client

An OIDC client registration identifies your app during sign-in. Its redirect URL tells AgentID exactly where the browser may return after authentication.

This registration creates credentials inside .env.local. Keep that file private because it can contain a client secret.

The CLI asks for project details in the terminal. It also opens the signed-in AgentID console in your existing browser for approval.

Choose Other OIDC when the provider picker appears.
Enter myapp as the application name.
Enter http://localhost:3000/auth/callback/agentid as the redirect URL.
Keep the standard openid, email, and profile scopes selected.
Enable the owner_email scope so the app can identify the human owner.
Approve the registration request in the AgentID console when the browser opens.

Start the guided AgentID registration by running this command:

npx @agentmail/agentid-cli init

What does this command do?

The CLI detects the project context and registers an OIDC client after browser approval. It returns the new client credentials directly to the waiting terminal.

The CLI writes the credentials to .env.local and binds them to this project. It also validates the discovery settings with the localhost callback.

The terminal should resume after approval. Your project now contains the generated client configuration for the registered localhost app.

Registration did not finish?

Complete the approval in the AgentID console before returning to the terminal.
Confirm that the terminal is still inside the Desktop myapp folder.
Check the callback value for a missing port or path if the CLI rejects the redirect URL.

Ask for help: Help me debug why the AgentID client registration did not finish.

Before you run the final check, consider whether the client binding and callback validation will both pass.

Verify the generated AgentID configuration without changing it by running this command:

npx @agentmail/agentid-cli doctor

What does this command do?

The doctor command checks the saved credentials and the project binding. It also checks the OIDC discovery data and callback configuration.

You should see the required checks complete without a failure. This confirms that the client ID and localhost redirect URL belong to the registered app.

Seeing a failed check?

Rerun the initialization command if browser approval ended before the terminal received the credentials.
Keep .env.local inside the myapp folder so the CLI can find the saved configuration.
Remove secrets and local file paths before sharing diagnostic output.

Ask for help: Help me understand which AgentID doctor check failed and how to fix it safely.

Your web app is running locally and registered as an AgentID client. Next up, you'll add the login route that starts the agent sign-in flow.

Add AgentID Sign-In

The AgentID client registration from the previous step gives your app a trusted return address. Your app still needs the browser journey that starts a sign-in.

In this step, you'll connect the generated client settings to your OpenID Connect library. That connection gives your app a login route plus a callback route.

You'll finish with a sign-in button that sends the browser to AgentID.

In this step, get ready to:

Start the AgentID authorization flow from a login route.
Handle the authorization response through a callback route.
Display an AgentID sign-in button that redirects visitors.

Start the authorization flow

A login route begins the authorization code flow. Your OpenID Connect library creates a security check before sending the browser to AgentID.

How does the login route stay secure?

The generated configuration points your library at https://auth.agentid.com/.well-known/openid-configuration. The discovery document supplies the current authorization endpoints plus signing keys.

The generated client ID identifies your local web app to AgentID.
The registered localhost redirect URL tells AgentID where to return the browser.
A state value connects the outgoing request to the returning response.
PKCE with S256 protects the authorization code during the redirect flow.

Open your local web app in the code editor you used in the previous step.
Press Cmd+Shift+F (macOS) or Ctrl+Shift+F (Windows) to open project-wide search.
Search for the generated client ID from your AgentID configuration.
Select the matching configuration file from the search results.

You should see the generated client ID beside the localhost redirect URL. This confirms that you found the configuration created for this app.

Add a GET handler at /login/agentid through your framework's server-side routing area. Call your OpenID Connect library's authorization helper with the generated AgentID client configuration.
Save the server-side route file.
Switch to the terminal you used for the local web app.
Start the app with the same local command you used after scaffolding it.
Open the /login/agentid path on the localhost origin from your generated redirect URL.

You'll leave the local app through an AgentID authorization redirect. You have the first half of the flow working.

Still on the local app?

Confirm that /login/agentid accepts a GET request.
Check that the route calls the authorization helper from your OpenID Connect library.
Compare the client ID used by the route with the generated client ID in your project configuration.

Ask for help: Why does my AgentID login route stay on localhost instead of redirecting?

Handle the authorization response

AgentID returns the browser to the localhost redirect URL registered for your client. The callback handler uses the returned authorization code to finish the OpenID Connect exchange.

What happens in the callback?

The callback compares the returned state with the value saved before the redirect.
The OpenID Connect library uses the saved PKCE verifier to exchange the returned code.
The library checks the returned iss value against the AgentID issuer.
The library verifies the signed ID token before accepting the identity.

Return to the server-side routing area in your code editor.
Add a GET handler at the exact path from the generated localhost redirect URL. Call your OpenID Connect library's callback helper with the generated client settings plus the session storage used by the login route.
Save the callback route file.
Open a second terminal so the local app keeps running.

Before you check the configuration, do you think the login route plus callback route now form a complete OpenID Connect round trip?

Check the AgentID integration without changing it by running:

npx @agentmail/agentid-cli doctor

What does this check do?

The AgentID doctor checks the client credentials plus registered callback settings. It also checks the local provider configuration without rewriting your project.

You should see the required integration checks reported as passing. The server side is now ready to receive AgentID's authorization response.

Seeing a failed check?

Compare the callback route with the full localhost redirect URL stored in the generated configuration.
Check that the login route plus callback route use the same generated client settings.
Confirm that both routes use the same server-side session storage for the state value plus PKCE verifier.

Ask for help: Can you help me debug the failed AgentID doctor check?

Add the sign-in button

Visitors need a visible way to begin the login route. The button sends them to the route you just verified.

Return to the page component or template that renders your local app's main page.
Add a button labeled Continue with AgentID that navigates to /login/agentid.
Save the page file.
Refresh the local app in your browser.

You'll see the Continue with AgentID button on the page. You now have a visible entry point for agent sign-in.

Before you click the button, where do you expect the browser to go?

Click Continue with AgentID.

You'll land on AgentID's sign-in or waiting page. That redirect proves your button reaches the login route.

Button not redirecting?

Check that the button navigates to /login/agentid.
Confirm that the local app is still running in the first terminal.
Reload the local page after saving the page file.

Ask for help: Why does my AgentID button fail to start the redirect?

Your app can now hand visitors to AgentID through OpenID Connect. Next, you'll complete the sign-in as your practice agent and inspect the identity returned to your app.

Sign In as Your Agent

Your app already sends visitors to AgentID through OpenID Connect. Its callback route is ready to handle the response.

Now you need to prove that the flow identifies the agent as the signed-in subject. The resulting authenticated session must expose a profile that names the human owner.

In this step, get ready to:

Start the existing AgentID sign-in flow.
Complete authentication as the practice agent.
Confirm that the profile separates the agent from its human owner.

Start the sign-in flow

The sign-in begins in your local app. AgentID verifies the practice agent before returning the browser through your existing callback route.

Switch back to the local app page from earlier.
Refresh the page.

You should see the Continue with AgentID button on the page.

Missing the sign-in button?

Confirm that you returned to the same localhost address used in the previous step.
Check the terminal from earlier for the running app process.

Ask for help: My local app is running but the AgentID sign-in button is missing. Can you help me check the page and app process?

Complete the AgentID approval

AgentID can continue automatically when the browser already recognizes the practice agent. A browser without that session asks the human owner to approve the agent.

Before you start, do you expect the app to recognize the practice agent or your personal account?

Click the Continue with AgentID button.

The first approval can take up to five minutes. Keep the sign-in page open while AgentID processes the request.

✔️ AgentID recognizes the agent

The browser already holds the practice agent's AgentID session. AgentID can complete the approval without asking for owner credentials.

Keep the AgentID page open until the browser returns to your local app.

Your local app should load the profile page after the callback finishes.

ⓧ AgentID asks for manual approval

Manual approval lets the owner choose which agent may sign in. Your app does not receive the owner's account password.

Select Approve manually on the AgentID page.
Sign in to the AgentMail console with the account that owns the practice agent.
Select the practice agent's inbox.
Approve the requested identity disclosure.
Keep the browser tab open until it returns to your local app.

Your local app should load the profile page after the approval completes.

Good progress. Your app now holds an authenticated session for the practice agent.

Stuck before the callback?

Keep the AgentID page open for up to five minutes if the approval is still processing.
Compare the callback address in the browser with the localhost redirect URL in your project configuration if AgentID returns an error.
Select the practice agent linked to your owner account if manual approval shows multiple identities.

Ask for help: My AgentID sign-in is not returning to the local app. Can you help me check the approval and redirect URL?

Verify the agent profile

The callback proves that AgentID returned an authorization response. The profile proves that your app connected that response to the correct agent identity.

Before you check the page, which identity do you expect the profile to show as the signed-in subject?

Compare the displayed agent email with the AgentID-issued email from earlier.
Confirm that the owner field identifies the human associated with the practice agent.

The agent email should match the practice identity. The owner field should identify the human behind that agent.

What does this profile prove?

The agent identity tells your app which automated actor signed in. The owner identity gives that actor human accountability.

Together they let future activity records distinguish an agent action from a personal action.

Before you refresh, do you expect the sign-in button to return or the agent profile to remain?

Refresh the profile page.

You should still see the same agent identity and human owner. This confirms that the authenticated session remains active.

Does the profile disappear?

Repeat the sign-in from the local app if the sign-in button returns after a refresh.
Allow site data for the local app in your browser if the session disappears immediately.
Repeat the approval with owner disclosure if the agent appears without its human owner.

Ask for help: My AgentID profile or owner information disappears after I refresh. Can you help me troubleshoot the session?

Your practice agent can now sign in with its own identity. Next up, you'll give that agent a protected action and record its work in the activity log.

Record Agent Activity

The practice agent already signs in through AgentID. Its profile separates the agent identity from the associated human owner.

The final gap is attribution. An activity log must record the agent as the actor whenever the protected action succeeds.

In this step, get ready to:

Add an action for the authenticated agent.
Record successful use of the action in an activity log.
Confirm that the log identifies the agent as the actor.

Add the agent-only action

An agent-only action needs a visible entry point protected by a server-side authorization check. The active session supplies proof that an authenticated agent can use it.

Switch back to the code editor from earlier.
Locate the page or route that renders the authenticated agent profile.
Implement one session-protected agent action on that authenticated profile page.
Save the changed app files.
Return to the profile page in your browser.
Reload the profile page.

You should see a new control for the agent-only action beside the existing profile information.

What Makes the Action Agent-Only?

The control gives the authenticated agent a way to request the action. The server-side handler enforces the access boundary by requiring the active agent session.

Server-side authorization keeps the protection in a place the browser cannot bypass.

Don't See the New Action?

Confirm that you edited the page or route responsible for the authenticated profile.
Check that the new action uses the existing authenticated session.
Save the changed files before reloading the profile page.

Ask for help: My agent-only action does not appear on the authenticated profile page. Can you help me trace the profile route and session check?

Connect the activity log

Trustworthy attribution starts with the authenticated session. The action handler can use that session to identify the agent without accepting an actor identity from the browser.

Return to the code editor from earlier.
Locate the protected handler for the agent-only action.
Implement session-attributed activity logging inside the protected action handler.
Save the changed app files.
Return to the profile page in your browser.
Reload the profile page.

You should see the activity log ready to display a row after the agent completes the protected action.

How Attribution Stays Trustworthy

The handler creates one activity-log row only after the protected action succeeds.

The row receives its actor from the agent identity stored in the authenticated session. The human owner remains associated profile information.

Verify the recorded identity

Before you test the full flow, which identity do you expect the new row to name?

Use the new agent-only control once.

You should see one new activity-log row for the completed action.

Compare the row's actor tag with the agent identity shown on the profile.

The actor tag should match the authenticated practice agent identity.

Compare the row's actor tag with the associated human owner shown on the profile.

The actor tag should differ from the human owner identity. This proves that the app attributes the action to the agent that performed it.

Is the Activity Row Missing or Misattributed?

Confirm that the handler creates the row after the protected action succeeds.
Trace the row's actor value back to the agent identity in the authenticated session.
Check that the owner identity is used only as associated profile information.

Ask for help: My activity log is missing a row or identifies the human owner as the actor. Can you help me trace the identity source?

You have closed the identity gap in your app. The activity history now names the practice agent as the actor.

Secret mission

Audit Agent Attribution End to End

Your login flow works. Production teams also need evidence that attribution stays consistent after authentication. Follow the practice agent from the profile page into the activity log to prove who performed the agent-only action.

Clean Up Your Resources

Choose whether to keep your AgentID resources available, pause local testing, or remove the practice setup. The web app runs on your computer, so stopping its local process leaves no ongoing hosting cost.

Resources you used:

Registered AgentID OpenID Connect client with its generated client ID and localhost redirect URL.
Practice agent identity with its AgentID-issued email address and associated human owner.
Local web app process with an authenticated practice-agent session.

Keep everything running

No action is needed. Choose this if you want to continue testing agent sign-in or build more agent-only actions.

Keep the registered client available for future sign-in tests.
Keep the practice identity available so its AgentID-issued email can authenticate again.
Keep the local source files in their existing location.
Leave the local web app running only while you are actively testing it.

Pause - I'll come back to this later

Pausing ends the local web app process. The registered client and practice identity remain available for your next test.

Switch back to the terminal session running the local web app.
Close that terminal session to stop the app.
Refresh the local profile page in your browser.

You'll see that the localhost page is no longer available. This confirms that the local app has stopped.

Close the local profile page after confirming the app has stopped.

Delete - I don't want to use this again

Remove the remote AgentID resources used for testing. End the local app session after the remote cleanup is complete.

Deletion Is Permanent

Revoking the registered client prevents the app from starting new AgentID sign-ins. Deleting the practice agent identity removes the identity used throughout this project.

Your local source files remain in their existing location. This cleanup targets the registered client, the practice identity, and the running app process.

Revoke the registered client:

Return to the signed-in AgentID console from earlier.
Find the registered client using the localhost redirect URL recorded in your project configuration.
Open the matching client's details.
Use the client detail page's revocation control to revoke the client.
Approve the confirmation shown by the console.

You should see that the client is no longer active for new sign-ins. The local app can no longer begin a new login through that client.

Delete the practice agent identity:

Return to the practice agent identities view in the AgentID console.
Find the practice identity using its AgentID-issued email address.
Open the matching identity's details.
Use the identity detail page's deletion control to delete the identity.
Approve the confirmation shown by the console.

You should no longer see the practice agent identity in the console's identity list. This confirms that the remote practice identity has been removed.

Stop the remaining local process:

Switch back to the terminal session running the local web app.
Close that terminal session to stop the app.
Refresh the local profile page in your browser.

You'll see that the localhost page is no longer available. Your registered client is revoked and your practice agent identity is deleted.

Still See a Remote Resource?

Refresh the AgentID console before repeating a deletion. The resource list may still show an older page state.

Confirm that you selected the client with the localhost redirect URL from this project. Confirm that the deleted identity uses the practice agent's AgentID-issued email address.

help me identify the AgentID resource that still needs cleanup

Nice Work!

You did it! Your local web app now recognizes a signed-in practice agent through AgentID.

You've learned how to:

Create a dedicated agent identity with its own AgentID-issued email address. Link that identity to its human owner.
Register the local app as an OpenID Connect client with a generated client ID. Complete the sign-in flow through a localhost redirect URL.
Display the agent-owner relationship on an authenticated profile page. Record an agent-only action under the practice agent in the activity log.
Secret Mission: Take on an optional challenge to push your agent identity skills further.

Ready to quiz yourself?