Aiml Access Diagnostics

AI/ML Access Diagnostics

Diagnose why an AI/ML service call was denied. Walk the authorization chain hop by hop, name the hop that denied the call, and propose a scoped IAM policy for human review. Read-only throughout.

Checklist

Work through these steps in order. Each is detailed in its own section below.

• Step 1 — Classify the request: confirm the service is Bedrock or SageMaker, and that there is an observed failure (not a speculative audit). Stop otherwise.
• Step 2 — Establish identity and scope: record the agent's own identity, extract the principal/action/resource ARNs, and flag cross-account.
• Step 3 — Collect evidence, policy reads first: read the chain's policy documents by hand; use CloudTrail and simulation only as corroboration.
• Step 4 — Walk the chain: traverse the six hops in precedence order; do not stop at hop 1 just because it passed.
• Step 5 — Apply service-specific knowledge: rule out non-IAM denial causes for the service explicitly.
• Step 6 — Assign verdicts: give every hop exactly one token from the closed verdict set.
• Step 7 — Propose a policy: derive a scoped policy for human review; keep observed and commonly-required permissions labelled separately.
• Step 8 — Deliver the report: render per the report format, run the pre-render validation, then deliver.

Output Discipline

The report is the deliverable. Conversation around it is not.

• Do not narrate API calls. No per-call summaries, no interim results, no raw response extracts. A full diagnosis makes many reads; announcing each one buries the finding.
• Do not narrate plans or reasoning. No "Let me check...", "I'll now look at...", "Given the chain, I should...". Execute the step and move on.
• Do not echo raw API responses. Process them silently. Policy documents in particular are long, and pasting them displaces the diagnosis.
• Keep interstitial messages to one line. Speak between steps only at real milestones: starting, asking the user something, delivering, or erroring.
• Do not summarize after delivering. The report already contains the summary; restating it invites a shortened paraphrase to be read instead of the report.
• Never assess your own performance. Do not append a paragraph saying the diagnosis worked, was correct, handled a hard case, or caught something subtle. The reader evaluates the report; the report does not evaluate itself. Self-congratulation also lends unearned confidence to findings whose limitations the report has just carefully enumerated.
• Nothing follows the report except, at most, a single line offering a next action — saving an artifact, or running another failure. No recap, no restatement of the root cause, no commentary on the diagnosis.

Supported Services

If the request concerns an unsupported service, say so and do not attempt a partial diagnosis from the generic chain alone. The value of this skill is in the service-specific knowledge; without it the output would be a guess.

Architecture

• This skill (orchestrator): request classification, chain traversal order, verdict assignment, report rendering.
• Chain model: the six-hop authorization chain and its precedence rules — references/access-chain-model.md
• Data collection: the read-only API allowlist, error classification, and the structured object collection produces — references/data-collection.md
• Finding logic: verdict rules and body templates per failure class — references/finding-logic.md
• Report format: report structure and pre-render validation — references/report-format.md
• Service specifics: loaded only for the service in question — references/svc-bedrock.md, references/svc-sagemaker.md

Step 1: Classify the request

Classify before calling any tool. Two things must be established first.

1a. Which service?

Determine the AI/ML service from the error text, API name, or resource ARN. If it is not Bedrock or SageMaker, stop and report it as unsupported.

1b. Is there an observed failure?

This skill diagnoses failures. It does not audit permissions speculatively. If there is no failure to explain, say so and stop rather than producing a posture review.

Step 2: Establish identity and scope

1. Call sts:GetCallerIdentity to determine the account and the identity the agent itself is operating as. Record it — the report must state whose view this is.
2. From the error text, extract: the principal ARN, the action, and the resource ARN where present. Error strings of the form User: <arn> is not authorized to perform: <action> on resource: <arn> carry all three.
3. Determine whether the principal is in the current account. If the resource is in a different account, mark the request cross-account and follow the cross-account handling in references/finding-logic.md.

Step 3: Collect evidence — policy reads first

Policy documents are the primary evidence. Every hop except the organization SCP decision is decidable by reading the policies that govern it. CloudTrail and the policy simulator are corroboration, and the diagnosis must stand without either — in this runtime both are frequently unavailable, which is a characteristic of the environment rather than a permission gap. See references/data-collection.md.

Collect in this order:

1. The chain's policy documents. The caller's identity policies, the target role's trust policy and permissions, relevant resource policies, and the attached SCPs. Evaluate each by hand: match the action, match the resource ARN including its account and region fields, and check every condition key against what the failing call supplied.
2. CloudTrail, if the runtime permits it. Adds independent confirmation of the event and, more usefully, requestParameters — the passed RoleArn and any VpcConfig, neither of which appears in the error string.
3. Grant events preceding the denial, when CloudTrail is available — if any appear within ~10 minutes for the same principal or resource, a propagation delay is possible. See references/svc-bedrock.md for the Bedrock grant event names. Without CloudTrail, propagation cannot be ruled out; say so rather than ruling it out.
4. Simulation, if the runtime permits it. It contributes exactly one thing policy reading cannot: AllowedByOrganizations at hop 6. It cannot evaluate trust policies at all, and at hop 2 it is measurably wrong on correctly configured callers unless iam:PassedToService is supplied.

Where a policy read and simulation disagree, the policy read wins, except for AllowedByOrganizations.

If a collection step fails, record its status, distinguishing an unreadable policy from an operation the runtime does not permit. Never infer a configuration you could not read, and never infer one operation's availability from another's failure.

Step 4: Walk the chain

Traverse the six hops in the order defined in references/access-chain-model.md. Stop descending once a hop produces a definitive DENIED_BY, but still collect and report the remaining hops as context where the data is already in hand.

The most common outcome is that the caller's permissions are fine and the service role's permissions are not. Do not conclude at hop 1 simply because it passed.

Step 5: Apply service-specific knowledge

Load the matching references/svc-*.md and evaluate the non-IAM denial causes it lists. For Bedrock these include model subscription state, AWS Marketplace permissions, and propagation timing — none of which are IAM policy gaps, and all of which produce AccessDeniedException.

A diagnosis that checks only IAM and reports "your permissions are correct" while one of these is the true cause is the primary failure mode of this skill. Rule them out explicitly.

Step 6: Assign verdicts

Every hop gets exactly one token from this closed set. Definitions and assignment rules are in references/finding-logic.md. Never invent a token, and never write a verdict as free prose in place of one.

Never collapse ALLOWED_BUT_UNVERIFIABLE into an allow. Readable policies indicating an allow is not proof the live call succeeds.

Use WOULD_ALSO_DENY rather than contradicting yourself. If a hop below the root cause independently shows a denial, mark it as such. A hop whose finding says the call will fail must never appear in the chain table as allowing it.

Step 7: Propose a policy

Produce a policy document for human review. Two categories of permission, labelled distinctly and never merged:

The simulator does not generate policies. It attributes decisions. Do not present simulator output as a suggested policy.

Step 8: Deliver the report

Render per references/report-format.md, run the pre-render validation, then deliver.