Skip to content
Talk to an architect
Who and what has access

Every identity gets an owner, a scope, and an expiration.

Identity and access is the layer that decides who and what can reach the estate, covering human accounts, service accounts, keys, and the agents now arriving alongside them. Atlas Bench designs that architecture across Okta and Atlassian Guard and makes non-human identities ready for Agent SSO, so the next account of any kind arrives with an owner.

Human accounts, service accounts, keys, and agents, designed as one identity architecture across Okta and Atlassian Guard, with non-human identities ready for Agent SSO before an agent rollout rather than after.

identity owner expires one owner recorded, five unaccounted L1 L2 L3 L4

The problem

Most organizations cannot produce a list of who and what can reach their systems. Human accounts are the easy part. The service accounts, API keys, integration users, and agents outnumber them, and most were created for a project that ended years ago.

The gap shows up the moment someone asks a specific question. Which group grants this. Who approved that integration. What this agent will be able to reach on the day it is switched on. Those have answers only if identity was designed as one system rather than accumulated one exception at a time.

What the work is

Identity inventory and reconciliation

Every human and non-human account across the estate, reconciled against the people and systems that should exist. The accounts nobody can explain are the first finding, not the last.

Single sign-on and authentication policy

SSO across the estate, with authentication policies that cover employees, external vendors, and service accounts under one model rather than three.

SCIM and group provisioning

Directory-driven provisioning and group synchronization, so joiners, movers, and leavers change access automatically instead of by ticket.

Permission architecture

A group and permission model covering employees and external vendors, with vendor identity carried on group attributes rather than in someone's memory.

Agent SSO readiness

Bringing non-human identities into the same joiner, mover, leaver process as people, with Okta Agent SSO where it applies, so anything that runs gets an owner, a scope, and a review date before it gets access.

How it runs

  1. Discovery and current state

    2 to 3 weeks

    Working sessions with the teams who own access today, plus an export-driven analysis of every account, group, and integration. The output describes what exists, not what was intended.

  2. Design

    2 to 3 weeks

    The target identity model: authentication policies, group structure, provisioning rules, and the review cadence. Approved before anything changes.

  3. Implementation

    4 to 6 weeks

    SSO, SCIM, group provisioning, and permission schemes rolled out in a controlled sequence, highest-risk groups first.

  4. Handover

    2 weeks

    As-built documentation, administrator training, and the onboarding standard for the next service account or agent, walked through with your team rather than left in a folder.

What you get

  • An inventory of every human and non-human identity in the estate, with an owner named or flagged as unowned
  • Authentication policies covering employees, external vendors, and service accounts
  • SCIM group synchronization from your identity provider, with a documented attribute map
  • A group and permission model applied across the projects and spaces in scope
  • Onboarding standards for service accounts and agents, covering owner, scope, and expiry
  • An Agent SSO readiness plan: which non-human identities move first, and what each needs in place before it does
  • As-built documentation and administrator training so your team can run the model
Start here

Four layers. One accountable system of work.

The layer everyone wants sits on the layer everyone ignores. Every engagement starts at one of these four, and whichever door you come through, the other three are still load bearing.

L4

Agents and Automation

Rovo, Agents in Jira, Forge, MCP with Claude and Copilot, agent lifecycle, usage and cost governance.

2 services

Atlassian Anthropic
L3

Governance and Change

Permission architecture, audit and compliance, ITSM and change control, change management, strategic reporting and budgets.

4 services

Atlassian Guard Jira Service Management Strategy Collection Jira Align
L2

Platform and Migration

Migration of every kind, tool consolidation, licensing, standardization, the system of work.

3 services

Atlassian Miro AWS Azure
L1

Identity and Access

Human and non-human identity, SSO, SCIM, least privilege, access reviews, Guard cleanup, Agent SSO readiness.

2 services

Atlassian Guard Okta

load-bearing, bottom to top

Proof

109:1

Machine identities per human in the enterprise, up from 45:1 two years earlier. Seventy-nine of the 109 are agents.

Palo Alto Networks, 2026 Identity Security Landscape, 2,930 respondents. Earlier ratios: CyberArk Identity Security Threat Landscape, 2024 and 2025.

92%

Of security leaders say they lack full visibility into the machine identities already running in their environment.

2026 CISO AI Risk Report, 235 large-enterprise leaders.

9 in 10

Organizations that had a successful identity-related breach in the last twelve months. Identity is the attack surface now.

Palo Alto Networks, 2026 Identity Security Landscape, 2,930 respondents.

Questions we get

Do we need Atlassian Guard for this?
For the Atlassian side, yes. Guard is what carries SSO, SCIM, and the authentication policies. If you already run Okta or Entra as your identity provider, Guard is the connection point rather than a replacement, and the two get configured as one model.
We already have single sign-on. Is there anything left to do?
Usually a great deal. Single sign-on answers how a person authenticates. It does not answer which groups exist, who owns them, what a service account can reach, or when access is reviewed. Those are the parts that fail an audit.
Where do cleanup and access reviews fit?
In their own engagement, Guard cleanup and access reviews. The two often run together. Cleanup makes the accounts that already exist explainable, and the architecture here decides what every account after them looks like.
What does this have to do with agents?
An agent is an identity. It authenticates, it holds permissions, and it acts. If your joiner, mover, leaver process cannot describe one, nothing downstream can prove what it touched. That is why this work comes before an agent rollout rather than after.
Can you do this without disrupting people who are working?
Yes, and the sequence is designed around it. Discovery and design change nothing. Implementation runs group by group, highest risk first, and provisioning changes that affect login are applied outside working hours.
Who owns the model when you leave?
Your team. Administrator training and as-built documentation are deliverables rather than extras, and the onboarding standard for new identities is walked through with your people rather than handed over.
featured guide

When Atlassian accounts are not tied to your identity provider, people who have left the company can still log in with an old Atlassian password, and they keep using a license. Enforcing SSO through Okta and turning on user provisioning closes that gap first, and then standard groups let you control access by app and by space.

Read the guide

Recent resources

Find out who can reach what.

Fixed scope. The assessment starts at the identity layer: human and non-human access, the accounts nobody owns, and what has to be true before an agent gets one. You get the findings, the ownership gaps, and the order to close them in.

Get an agent readiness assessment

By sending this you agree to our privacy policy.

Not ready? Talk to an architect