Access Review Collection Playbook (Okta + AWS IAM + Datadog)

What You Will Learn

• If required catalogs are missing, ask the agent to import them and verify auth headers first.
• Run provider connectivity preflight before any collection.
• Collect identity and access posture with read-only commands/workflows.
• Normalize outputs into a single review-ready report shape.
• Handle partial provider failures with explicit gap reporting.
• Produce quarterly and incident summaries without exposing secrets.

Purpose

This playbook is for collecting access-review evidence from Okta, AWS IAM, and Datadog through an MCP-connected agent.

Use it for quarterly access reviews and incident response evidence collection when you need auditable, repeatable, read-only execution.

The guide is goal-oriented and non-deterministic: prompts define outcomes and safety constraints, while command/workflow selection adapts to each environment.

If required provider catalogs or auth headers are not yet configured, begin with an import-and-verify step before running collection prompts.

tip Before running prompts, ensure your agent is connected through MCP HTTP Server: `/docs/learn/mcp-http-server`.

tip If you still need to add or update required auth headers manually, use `/docs/learn/library-and-catalogs#headers-management` first.

tip Use the Workflows view to review run plans, approvals, and execution details: `/docs/learn/workflows-basics`.

Scope and Feasibility

In-scope outcomes for this playbook:

1) User and group inventory (identity state).

2) Role/policy/grant inventory (permission state).

3) Available audit/security event evidence per provider.

4) Unified summary with pass/fail coverage and unresolved gaps.

With provider authentication already configured, this guide is feasible for identity and permission collection across Okta, AWS IAM, and Datadog. Audit/event depth varies by provider endpoint availability and account configuration.

expected Expected result: a useful guide remains feasible even when one provider is partially unavailable, as long as preflight and gap reporting are enforced.

Validated Read-Only Signals

Representative evidence signals available through Oatty command catalogs:

Identity inventory: `github users:list`, `okta api:users:list`, `okta api:groups:list`, `aws #Action=ListUsers:list`, `datadog users:list`.

Permission posture: `aws #Action=ListRoles:list`, `aws #Action=ListPolicies:list`, `aws #Action=GetAccountAuthorizationDetails:list`, `datadog permissions:list`, `github repos:collaborators:list`.

Audit/event evidence: `okta api:logs:list` and provider-specific event endpoints where available.

expected This playbook remains useful even with partial provider availability, as long as outputs include explicit provider coverage and collection gaps.

How to Use This Guide (Goal-Oriented, NL-First)

Start each run with clear goals, time window, and allowed mutation policy (read-only by default).

Have the agent discover available commands/workflows first, then run preflight gates, then collect evidence in provider order.

Require normalized output sections and explicit coverage gaps rather than raw payload dumps.

tip If you need a refresher on command discovery and safe execution controls, see `/docs/learn/search-and-run-commands` and `/docs/learn/how-oatty-executes-safely`.

Prompt Patterns: Prompt -> Expected Agent Actions

Use these prompt patterns to drive consistent collection and reporting behavior with a connected agent.

Pattern 1: Auth and Connectivity Preflight

Run this first on every quarterly or incident pull.

Prompt:
Run a preflight for Okta, AWS IAM, and Datadog before we collect anything. If a catalog is missing, import it first, verify required headers, and give me a go/no-go summary.

expected Expected agent actions: import missing catalogs when needed, verify required headers, execute provider connectivity checks, and produce a go/no-go table before evidence collection.

Pattern 2: Collect Identity Inventory

Use this to collect users, groups, and account-level ownership context.

Prompt:
Collect a read-only identity inventory from Okta, AWS IAM, and Datadog. Return users, groups/teams, and account ownership in one normalized format.

expected Expected agent actions: run read-only identity commands per provider, map provider-specific fields to a shared schema, and return counts plus key identifiers.

fallback Representative commands include `okta api:users:list`, `okta api:groups:list`, `aws #Action=ListUsers:list`, `datadog users:list`, and `datadog roles:list`.

Pattern 3: Collect Permissions and Grants

Use this to capture effective permission posture and high-risk grant surfaces.

Prompt:
Collect read-only permission grants and role/policy mappings from Okta, AWS IAM, and Datadog. Highlight admin-equivalent access and anything with unclear ownership.

expected Expected agent actions: gather roles/policies/grants, classify privilege level, and flag high-risk assignments for reviewer follow-up.

fallback Representative commands include `aws #Action=ListRoles:list`, `aws #Action=ListPolicies:list`, `aws #Action=GetAccountAuthorizationDetails:list`, and `datadog permissions:list`.

Pattern 4: Collect Audit and Event Evidence

Use this to collect available audit/security events for the requested time window.

Prompt:
Pull read-only audit/security evidence for the last 90 days from available provider endpoints. Summarize key actions and call out any coverage gaps.

expected Expected agent actions: collect available event streams, summarize notable admin/security actions, and explicitly report provider-specific audit depth limits.

fallback For example, use `okta api:logs:list` where available and account for missing endpoints by emitting a structured collection gap section.

Pattern 5: Quarterly Review Output

Use this for governance-oriented review packets.

Prompt:
Create a quarterly access review summary with provider coverage, user/grant totals, high-risk findings, unresolved gaps, and prioritized remediation actions. Keep this read-only.

expected Expected agent actions: produce a concise executive summary plus reviewer-ready details and a clear remediation queue with owners.

Pattern 6: Incident Evidence Output

Use this for time-bounded incident response support.

Prompt:
For incident window <start> to <end>, collect read-only access and audit evidence. Return an actor timeline, affected identities, privilege changes, and confidence notes where data is missing.

expected Expected agent actions: constrain collection to the incident window, produce a timeline with confidence annotations, and separate confirmed evidence from assumptions.

Recommended Output Schema

Require this structure in every run output for consistency:

1) `run_scope` (quarterly or incident, time window, providers requested).

2) `provider_coverage` (success/fail/partial + reason).

3) `identity_inventory` (users, groups/roles, key counts).

4) `permission_posture` (grants/policies, high-risk findings).

5) `audit_evidence` (events collected + notable actions).

6) `collection_gaps` (endpoint limitations, blocked data, or unavailable provider responses).

7) `recommended_next_actions` (prioritized remediation and owners).

tip Keep raw secrets and token-like values redacted in both terminal output and exported summaries.

Safety and Review Controls

Run this playbook in read-only mode by default and reject any prompt that implies mutation unless explicitly approved.

If any provider preflight fails because of endpoint/scope limitations, continue with partial collection only when requested and always include a remediation plan.

Use workflow and tool-call review in the TUI while the agent is connected to monitor actions in real time.

tip For manual review workflows and run approval practices, see `/docs/learn/workflows-basics`.

Next Steps

If you need additional provider coverage (for example, GitHub or AWS CloudTrail), extend catalogs and add matching read-only collection steps.

Export your finalized collection workflows and reporting templates into repository docs for repeat quarterly execution.

tip Import and tune catalogs with `/docs/learn/library-and-catalogs` before adding new provider goals.