Published by Roast & Rise
Agent Identity and Access: Treat Every Agent Like a New Hire
Give every sanctioned agent a clear owner, controlled access, visible actions, and a clean exit.
Build the identity controls your agents need before forgotten credentials become live exposure. You will create an agent register, tighten one high-risk access profile, and rehearse offboarding.
Course thesis
Agent credentials deserve the same lifecycle discipline as a human hire. The supplied research reports a 45:1 machine-to-human identity ratio, widespread agent use, and a severe ownership gap. A maintained register, narrow access boundary, and rehearsed revocation path turn invisible credentials into accountable identities.
What you leave with
By the end, you will have a working agent register, a least-privilege review for one high-risk agent, and a runbook that removes access when an agent leaves.
For
Founders, IT and security leads, and hands-on operators responsible for sanctioned AI agents or automations, especially teams that have created API keys without a shared identity register or retirement process.
Workflow
Agent access management: discover sanctioned agents and automations with credentials, register each identity, assign a human owner, define its minimum access, log high-risk actions, and revoke access at retirement or compromise.
Change
Replace scattered, undocumented agent credentials with one maintained agent register. Every discovered sanctioned agent has a named human owner, an explicit permission scope, action logging where risk requires it, and a tested revocation path.
What you can do
Use these as checks while you move through the plan.
Build a usable register of sanctioned agents, automations, credentials, access, and ownership.
Assign accountable human ownership and expose unresolved machine identities.
Reduce one high-risk agent to a justified, reviewable access boundary.
Rehearse credential revocation and leave evidence that access can be closed.
Chapters
01
Give Every Agent a Name and an Owner
Create a controlled register that makes every discovered agent identity visible, traceable, and human-owned.
Agent access cannot be controlled until each machine identity is visible and owned. The supplied research describes a 45:1 machine-to-human identity ratio and reports that 51% of organisations lack a clear AI identity owner. Scale makes informal memory a weak control.
Start with credentials, since names inside agent platforms rarely reveal the full identity. Search one bounded workflow across its agent platform, automation tool, credential store, cloud console, and team records. Capture sanctioned agents and automations that authenticate to another system. Record where each credential is managed. Never paste the secret itself into the register.
A useful entry shows reach. List the systems the agent can access and summarise its current permission scope, even when that scope still needs review. Mark whether activity is logged and record the known revocation path. Later chapters will tighten access and make retirement executable. Here, the job is visibility and accountability.
Assign one human owner who can explain the agent’s purpose, approve access changes, respond to suspicious activity, and decide when access ends. A team name or vendor is not accountable enough. Ask the named person to confirm responsibility.
Quality checklist
Every discovered identity has its own entry.
Each entry names one accountable human.
Credential locations exclude secret values.
Unknowns have an owner and resolution date.
Common mistakes
Using the API key label as the agent identity.
Recording the tool while missing downstream systems.
Pasting live secrets into the register.
Silently guessing when evidence is missing.
Checkpoint
Can a named person now explain the purpose, reach, and credential location of every agent you found?
Exercise
Sweep One Workflow
- Choose one live workflow or platform with sanctioned agents and automations.
- Search its agent list, integrations, credential store, cloud console, and team records for active credentials.
- Create one register entry for every identity found. Mark missing facts as unknown.
- Ask each named human owner to confirm responsibility. Assign unresolved entries a follow-up owner and date.
Use this at work tomorrow
Search one platform for active agent credentials and register every identity you find.
02
Draw the Access Boundary
Define the smallest observable access boundary that lets one high-risk agent complete its required task.
Your agent register shows what exists, who owns it, and where it can reach. Now turn one high-risk entry into a boundary the system can enforce.
Start from the agent’s required task. For each resource it touches, separate the actions it must perform from permissions granted through convenience, inherited roles, or setup defaults. Read, write, execute, approve, and administer are different powers. Record them separately. Keep access only when its owner can connect that action to the required task.
Make denied actions explicit. This prevents broad access from creeping back during troubleshooting or later configuration changes. If a permission cannot be verified or safely changed today, mark it as an assumption to validate, assign a change owner, and set a review date. Uncertainty needs a deadline.
Access also needs visibility. Require reviewable logs for actions that can change data, execute workflows, approve outcomes, alter access, or administer systems. A useful log connects the agent identity to the action, target, time, and result. Confirm that the accountable owner can retrieve it. Logging that exists but cannot be reviewed offers little control.
Quality checklist
Every allowed action supports the required task.
Denied actions are explicit.
Unverified permissions have an owner and review date.
High-risk logs are retrievable by the accountable owner.
Common mistakes
Keeping inherited roles without inspecting their permissions.
Using one broad scope across unrelated resources.
Assuming enabled logging means logs are retrievable.
Removing access before checking workflow dependencies.
Checkpoint
Can the owner justify every retained permission and retrieve logs for each high-risk action?
Exercise
Set One Agent’s Access Boundary
- Choose one high-risk agent from your register based on access reach and action power.
- Write its required task, then inspect what it can read, write, execute, approve, or administer.
- Keep only task-linked actions; record explicit denials and queue unsafe changes with an owner and date.
- Mark high-risk actions that need logs, then confirm the owner can retrieve one reviewable record.
Use this at work tomorrow
Ask one agent owner to justify every permission and retrieve a log for one high-risk action.
03
Make Retirement Real
Create a repeatable offboarding runbook that revokes an agent’s access, verifies closure, and leaves an auditable record.
An agent is still active while any usable credential or connected dependency survives. Changing its status to “retired” closes a record. Verified revocation closes access.
Your agent register and access profile already show who owns the selected agent, where its credentials live, what it can reach, and which actions matter. Turn that knowledge into an offboarding runbook someone else can execute under pressure. The runbook needs a clear trigger, one decision owner, the full revocation sequence, and proof that access has ended.
Sequence matters. A credential may feed scheduled jobs, webhooks, integrations, or downstream service accounts. Removing it blindly can interrupt shared workflows. Leaving one dependency untouched can preserve access. The runbook should therefore connect every credential to its dependencies and define the order for disabling them.
Closure requires a verification test. Use a safe dry run, test environment, temporary credential, or approved maintenance window. Record the result where the owner and reviewer can retrieve it. If safe rehearsal is currently impossible, state that as an assumption to validate and assign a date to resolve it.
Quality checklist
Every known credential and dependency appears in the sequence.
One named person owns the retirement decision.
The verification test proves access has ended.
Closure evidence is retrievable from the register.
Common mistakes
Deleting the agent before tracing connected jobs and integrations.
Revoking the obvious key while leaving secondary credentials active.
Using a vague trigger such as “when no longer needed.”
Storing closure evidence in a private message thread.
Checkpoint
Can another operator follow the runbook, prove access is gone, and update the register without relying on your memory?
Exercise
Rehearse the Agent’s Exit
- Select the high-risk agent reviewed in Chapter 2 and copy its owner, credentials, reach, and dependencies into the runbook.
- Define retirement, replacement, and compromise triggers, then name the person authorised to start revocation.
- Write the revocation sequence from dependent workflows through every credential and connected identity.
- Rehearse safely using a test environment, temporary credential, or approved window. Capture proof that authentication or the target action fails.
- Record the evidence location, closure owner, and required register update.
Use this at work tomorrow
Draft and safely test the verification check for revoking one high-risk agent credential.
30-day path
Days 1 to 5: Name an inventory lead, choose the register location, and sweep credential stores, agent platforms, automation tools, cloud consoles, and team records.
Days 6 to 12: Complete entries for every discovered sanctioned agent. Resolve missing owners and escalate credentials nobody accepts.
Days 13 to 21: Rank agents by access risk. Apply the least-privilege checklist to one high-risk agent and enable reviewable logs for its sensitive actions.
Days 22 to 30: Write the offboarding runbook, rehearse it on the selected agent, close gaps, and set a recurring owner review.
Success signals
100% of agents found during the 30-day inventory have a register entry, named human owner, permission scope, and revocation path.
No unresolved owner field remains open without a named escalation owner and resolution date.
One high-risk agent has documented permission reductions or explicit justification for every retained permission.
High-risk actions for the reviewed agent produce logs that an accountable owner can retrieve.
One offboarding rehearsal successfully revokes access, verifies failure, and records evidence.
The register receives a recurring review date and a named maintainer.
Reflection prompts
Where does this topic show up in real work?
What behavior should change first?
What evidence would prove this Riseplan worked?
Manager checklist
Choose one owner for the behavior change.
Use the exercise on live work.
Review the output before scaling the habit.
Decide what changes after 30 days.
In this library
Related RisePlans
Agentic Work Redesign Sprint
Learn how to redesign work for teams using AI agents to handle delegated, long-running, and cross-functional tasks. Build a new operating model that makes room for parallel delegation, reusable instructions, modern review cycles, and the next level of team collaboration.
From Chatbots to Superagents
Stop settling for one-off chatbot interactions. This plan shows you how to delegate real, repeatable work to AI agents with control, confidence, and results your team can trust.
AI Search Visibility: A Practical Sprint
Audit how your company appears in AI search, publish verifiable source pages, set crawler policy, and measure changes in Search Console.
Want this shaped around your company?
Risey can research your company foundation first, then build a version of this path around your real workflows, customers, and culture.
Start with your company