Okta
Purpose
Query and administer Okta directory objects (users, groups, apps, assignments) through connected tools with least privilege and verified API responses.
When to Use
- User asks about Okta users, groups, MFA status, or app assignments.
- Access reviews: who has an app, which groups grant a role.
- Provisioning or deprovisioning tasks when write tools and approval exist.
- Troubleshooting login or SSO issues tied to Okta configuration.
When NOT to Use
- Non-Okta IdP (Azure AD-only, etc.) without Okta connection.
- Broad IAM architecture design → provision-access, author-iac.
- Skill repo authoring → create-skill / publish-skill.
Expected Outcome
- User/group/app IDs and assignment state from tool output.
- Clear before/after on changes the user approved.
- Explicit stop when Okta admin API access is missing.
Inputs to Gather
- Okta org/domain and policy context if multi-org.
- User email, login, or Okta ID; group name; app name/ID.
- Whether change is read-only lookup vs approved write.
- Ticket or approval reference for production access changes.
Workflow
- Confirm Okta MCP tools; prefer search/list before get by guess.
- Resolve user or group canonical ID.
- For access questions: trace user → groups → app assignments (or direct assignment).
- For writes: restate action, require confirmation, apply minimal change.
- Verify post-change state with a read call.
- Summarize without exposing secrets, recovery codes, or full profile PII unnecessarily.
Domain guidance
- Search before mutate — email/login lookup before updates.
- Group vs direct assignment — explain effective access path.
- Lifecycle — staged, active, suspended, deprovisioned; do not delete users without explicit approval.
- App links — distinguish SAML/OIDC apps and assignment scope (user vs group).
- Tool schemas only — never fabricate assignment state.
Examples
User: "Does alex@company.com have the Admin console app?"
→ Find user, list group memberships and app assignments, state effective access and source (group vs direct).
User: "Add new hire to Engineering and Slack SSO."
→ Confirm groups exist, add user to groups, verify app assignment policy, report final state.
Tool Availability Rules
| Access |
Behavior |
| Full tool access |
Query and apply approved directory changes. |
| Read-only |
Directory investigation only; output steps for writes. |
| No integration |
Do not fabricate Okta records. |
Related tool sets
Review / Decision / Execution Criteria
- Cite user ID, group ID, and app ID in summaries.
- Treat deactivation and group removal as high impact—confirm twice.
- Follow least privilege; prefer group-based access over one-off grants.
Output Format
- Question and objects resolved (user/group/app IDs).
- Current state (memberships, assignments).
- Changes made (if any) with verification read.
- Blockers.
- Next steps or approval needed.
Quality Bar
- Suitable for IT/access review audit trail tone.
- No spreadsheet/A1 patterns.
Safety and Boundaries
- Do not expose passwords, MFA seeds, or API tokens.
- Do not bulk-modify production access without explicit approval.
- Do not fabricate assignment or login events.
Escalation / Dispatch Rules
- Broader access provisioning workflows → provision-access.
- Security review of new apps → threat-modeling, flag-security-issues.
References
skills/old_skills.json (okta).skills/skill.instruction.md, skills/meta.instructions.md
1---2name: okta3description: Manages Okta users, groups, and application assignments via connected directory integration. Use when looking up identity records, group membership, or app access—not generic spreadsheet operations.4---56# Okta78## Purpose910Query and administer Okta directory objects (users, groups, apps, assignments) through connected tools with least privilege and verified API responses.1112## When to Use1314- User asks about Okta users, groups, MFA status, or app assignments.15- Access reviews: who has an app, which groups grant a role.16- Provisioning or deprovisioning tasks when write tools and approval exist.17- Troubleshooting login or SSO issues tied to Okta configuration.1819## When NOT to Use2021- Non-Okta IdP (Azure AD-only, etc.) without Okta connection.22- Broad IAM architecture design → **provision-access**, **author-iac**.23- Skill repo authoring → **create-skill** / **publish-skill**.2425## Expected Outcome2627- User/group/app IDs and assignment state from tool output.28- Clear before/after on changes the user approved.29- Explicit stop when Okta admin API access is missing.3031## Inputs to Gather3233- Okta org/domain and policy context if multi-org.34- User email, login, or Okta ID; group name; app name/ID.35- Whether change is read-only lookup vs approved write.36- Ticket or approval reference for production access changes.3738## Workflow39401. Confirm Okta MCP tools; prefer search/list before get by guess.412. Resolve user or group canonical ID.423. For access questions: trace user → groups → app assignments (or direct assignment).434. For writes: restate action, require confirmation, apply minimal change.445. Verify post-change state with a read call.456. Summarize without exposing secrets, recovery codes, or full profile PII unnecessarily.4647## Domain guidance48491. **Search before mutate** — email/login lookup before updates.502. **Group vs direct assignment** — explain effective access path.513. **Lifecycle** — staged, active, suspended, deprovisioned; do not delete users without explicit approval.524. **App links** — distinguish SAML/OIDC apps and assignment scope (user vs group).535. **Tool schemas only** — never fabricate assignment state.5455### Examples5657**User:** "Does alex@company.com have the Admin console app?"58→ Find user, list group memberships and app assignments, state effective access and source (group vs direct).5960**User:** "Add new hire to Engineering and Slack SSO."61→ Confirm groups exist, add user to groups, verify app assignment policy, report final state.6263## Tool Availability Rules6465| Access | Behavior |66|--------|----------|67| Full tool access | Query and apply approved directory changes. |68| Read-only | Directory investigation only; output steps for writes. |69| No integration | Do not fabricate Okta records. |7071### Related tool sets7273- `okta`74- `custom-apis`7576## Review / Decision / Execution Criteria7778- Cite user ID, group ID, and app ID in summaries.79- Treat deactivation and group removal as high impact—confirm twice.80- Follow least privilege; prefer group-based access over one-off grants.8182## Output Format83841. Question and objects resolved (user/group/app IDs).852. Current state (memberships, assignments).863. Changes made (if any) with verification read.874. Blockers.885. Next steps or approval needed.8990## Quality Bar9192- Suitable for IT/access review audit trail tone.93- No spreadsheet/A1 patterns.9495## Safety and Boundaries9697- Do not expose passwords, MFA seeds, or API tokens.98- Do not bulk-modify production access without explicit approval.99- Do not fabricate assignment or login events.100101## Escalation / Dispatch Rules102103- Broader access provisioning workflows → **provision-access**.104- Security review of new apps → **threat-modeling**, **flag-security-issues**.105106## References107108- `skills/old_skills.json` (`okta`).109- `skills/skill.instruction.md`, `skills/meta.instructions.md`
poly-gents