How I think about objectives

I did not want teams to have to translate every identity problem into a rigid sequence of rules and tickets. Instead, they tell Offroad the outcome they want to achieve. The agent determines which identities, systems, evidence, policies, and approvals are relevant, then carries the work forward.

Here is a straightforward example I used while thinking through the system:

Remove all unused Salesforce administrators.

At first, this sounds like a simple query. It is not, removing an admin role safely requires more than finding accounts that have not logged in recently. The agent has to identify every human and non-human administrator, examine how the access was granted and used, find the owner, check business dependencies, and determine whether an apparently dormant account supports an integration, recovery workflow, or periodic process.

We built the objective so it can run every Monday at 10:00 a.m. Clear, policy-approved cases can be remediated automatically. When business judgment is required, the agent sends the right owner a completed investigation and recommended action. After the decision, it makes the approved change and verifies that effective access was removed.

For me, the outcome is not a cleaner list of administrators. It is administrative access that stays justified, current, and least-privileged without creating another recurring manual process.

Why I made context a core part of the system

One of the earliest design decisions I made was that an identity agent cannot make reliable decisions from entitlement data alone. Access that appears excessive may support a critical business process, while activity that appears authorized may be part of an attack.

That is why we built an Identity Fabric that connects identities, permissions, activity, sessions, devices, tickets, ownership, policy, and business context across more than 250 sources. I think of it as giving the agent enough context to answer four questions:

• Who or what owns the identity, and why does the access exist?
• How is the access being used, and does that usage match the identity’s role or purpose?
• Which systems or processes depend on it, and what could break if it changes?
• What risk could the access create, and who should approve the decision?

I also learned that some of the most important identity knowledge does not live in a clean database. It is buried in old tickets, Slack or Teams conversations, previous approvals, and exceptions that exist in someone’s memory. We built contextual memory so the agent can retain that organizational knowledge and apply it to future investigations, instead of making teams reconstruct the same history every time an issue returns.

Where I think this model is most useful

Once we had the core model working, I saw the same pattern across many of the identity tasks that consume security and IAM teams every day.

Enforce least privilege and clean up access drift

For least privilege, I wanted the agent to do more than flag a broad role. It monitors sensitive roles and permissions, determines whether they are still justified, and removes or narrows access that has become stale or excessive. For an internal mover, it compares previous and current roles, effective permissions, activity, approvals, and business ownership, then recommends what should be retained, removed, or made temporary and verifies the approved changes.

Complete a phishing-resistant MFA rollout

A phishing-resistant MFA rollout is another good example of why execution matters. Changing a setting is the easy part. Teams still need to identify affected users and incompatible workflows, avoid lockouts, coordinate communication, manage exceptions, follow up with people who have not enrolled, and verify adoption. We designed an Offroad Agent to manage that process from the initial assessment through confirmed rollout completion.

Offboard contractors when the HR trigger is missing

Contractor offboarding exposed a different engineering problem: the trigger itself may be missing. When no reliable HR event reaches the identity team, the agent can identify the sponsor and map the contractor’s accounts, roles, groups, sessions, tokens, OAuth grants, and secondary identities. It coordinates the decision, removes approved access, revokes active sessions and tokens, and verifies that indirect access paths are closed.

Govern service accounts, API tokens, and machine identities

Non-human identities were especially interesting to build for because they often outlive the workflow that created them. We connect service accounts, API keys, tokens, machine identities, CI/CD identities, and integrations to ownership, purpose, permissions, activity, dependencies, and blast radius. That lets an agent distinguish an abandoned credential from an account supporting a periodic process, assign missing ownership, rotate risky credentials, right-size permissions, and verify that remediation did not interrupt a legitimate dependency.

Keep OAuth applications under continuous review

I do not think an OAuth consent decision should be treated as a permanent business justification. Our agents evaluate applications using ownership, permissions, token age, installation scope, activity, connected systems, and business purpose. They surface abandoned or overprivileged applications, route unclear cases to the right owner, revoke unnecessary grants, and confirm that the access path was closed.

Treat AI agents as identities from the beginning

AI agents made this lifecycle problem even more obvious to me. They can call APIs, change data, and operate continuously, but they do not have a natural HR lifecycle. We map each agent to its owner, intended purpose, credentials, permissions, connected systems, activity, and blast radius. Security defines the guardrails, while the team that created the agent remains accountable for its lifecycle. Offroad flags unclear ownership, missing expiration dates, excessive permissions, activity outside the approved task, and access that has outlived its purpose.

Investigate activity that looks legitimate

Another principle I kept in mind is that not every unusual action is malicious, and not every permitted action is safe. A valid user can download sensitive data from an unmanaged device, a compromised session can operate during normal business hours, and an AI agent can use an approved permission outside its intended task. Offroad Agents investigate identity, access, device, session, activity, policy, and business context to determine whether the behavior aligns with the approved authority and purpose. When the evidence supports a threat, they can revoke sessions, disable tokens, remove risky access, contain the identity, or route the full investigation to the person who needs to decide.

Answer identity questions and create continuous reporting

I also wanted the same system to answer operational questions, not just react to alerts. Teams can ask which service accounts have no owner, which OAuth apps can write to sensitive data, where privileged access changed this week, or which risks remain open by business owner. Offroad Agents investigate across connected systems, return the answer with evidence and recommended next steps, and turn the request into a live report or continuous monitor.

How we designed autonomy without removing human control

This was the part I was most careful about. Identity changes can lock out employees, interrupt production workflows, disable integrations, or remove access granted for a legitimate exception. We designed Offroad Agents to operate within the organization’s policies, approval paths, and action boundaries. They resolve clear, policy-approved issues directly, while sensitive, ambiguous, or high-impact changes are routed to the appropriate person with the investigation already completed.

I wanted every action to be explainable after the fact. We record the evidence, decision, approval, change, and verification result. Where the connected system supports it, Offroad also preserves the relevant previous configuration so teams have a recovery path if new context appears or the change has an unexpected effect.

I do not think the goal is to remove people from identity decisions. Human judgment should remain where it adds value. The repetitive work required to reach that judgment no longer has to remain manual.

The metric I care about: verified resolution

I do not think findings, completed reviews, or closed tickets prove that risk was removed. An access review can reach 100 percent completion while identities remain outside its scope. A ticket can close while active sessions or inherited access survive the change. An OAuth application can be approved once and remain overprivileged for years.

The outcome I care about is verified resolution: the risk was investigated, the correct person was involved when necessary, the approved action was completed, effective access changed, and the result was confirmed.

That is what my team and I built Offroad Agents to deliver. They are not another dashboard for identity teams to monitor. They are an AI-native identity security team that continuously discovers, investigates, remediates, and verifies identity risk across humans, non-human identities, and AI agents.

Frequently asked questions

What are identity security agents?

I think of identity security agents as AI agents that investigate and resolve identity risk across human, non-human, and AI identities. They connect access with activity, ownership, policy, dependencies, and business context, then remediate approved risks or route sensitive decisions to the right person.

What tasks can Offroad Agents perform?

Offroad Agents are designed to handle any task or investigation within the identity domain across the applications and systems connected to Offroad. A team defines the objective in plain language, and the agents gather the relevant context, determine the workflow, coordinate approvals when needed, and take the appropriate action based on what they find. That can include removing unused access, monitoring sensitive permissions, coordinating phishing-resistant MFA rollouts, managing contractor and internal-mover access, governing service accounts and OAuth applications, securing AI-agent identities, investigating runtime activity, and creating continuous identity reports. These are examples, not a fixed menu of workflows.

Can Offroad Agents remediate identity risks automatically?

Yes, when the evidence is clear and the action is permitted by organizational policy. We intentionally route sensitive, ambiguous, or high-impact decisions to the appropriate owner or approver with the investigation and recommendation already prepared.

Can identity workflows run on a schedule?

Yes. We designed an objective to run once, on a recurring schedule, or continuously as identities, access, and activity change. For example, an agent can review unused Salesforce administrators every Monday morning and carry each case through investigation, approval, remediation, and verification.

How are Offroad Agents different from traditional identity tools?

Traditional identity tools typically show what access exists, surface a finding, or create a ticket. Offroad Agents carry the work through investigation and resolution. They gather and connect context from identity providers, SaaS applications, endpoint and activity data, HR systems, tickets, policies, and business owners to understand why access exists, how it is being used, what depends on it, and what could break if it changes. They then use that context to determine the right path, coordinate decisions, execute approved actions, and verify the outcome.

‍