Shadow AI discovery from Bedrock billing

AWS billing can reveal Bedrock usage that needs an owner and an approval check. Review the account, caller identity, allocation tags, model billing route and reporting delay before classifying the activity. A missing or zero-cost line leaves several possible explanations open.

This adds a financial evidence source to shadow AI discovery. Treat unregistered usage as a lead for investigation. A cost record alone establishes neither the employee's intent nor a policy breach.

Start with the billing population

AWS's Bedrock cost-management guide describes attribution through identity and tags, delivered as aggregated billed amounts in Cost Explorer and Cost and Usage Reports. These reports aggregate usage; they provide no per-request row.

Record the payer and linked-account scope, reporting dates, service filters and selected cost measure. Keep those choices with the export so another reviewer can explain what the report included. Check relevant model-provider billing categories before treating a service-only view as complete.

For example, AWS's Claude Opus 4.8 model card says charges are billed through AWS Marketplace under the model provider. That documented example makes a narrow Amazon Bedrock service filter worth reviewing.

Trace a role to an accountable owner

Bedrock's IAM attribution documentation describes capturing the caller's identity. The cost-attribution FAQ says the caller-identity column requires a CUR 2.0 export with that option selected. Existing exports need their configuration checked.

When a gateway calls Bedrock for several users, the recorded caller can be the gateway's role. Attribute the role to the application owner first. Any finer attribution needs a documented identity design, such as appropriate session tags, plus a review of the privacy implications.

Avoid placing email addresses or sensitive content in tags. Prefer a stable internal reference with controlled access to the owner mapping. A shared service identity can support application-level discovery while leaving the individual user unresolved.

Explain what the tags cover

Application inference profiles provide one Bedrock allocation method. AWS documents using the profile ARN for supported InvokeModel and Converse calls so usage receives the profile's tags. Coverage depends on the route and identifier the application actually uses.

AWS's cost-attribution practices also explain that omitted tags do not cause Bedrock to reject a call. An untagged-cost bucket therefore deserves its own owner and review procedure.

Compare the profile, role and account identifiers with the approved application register. A mismatch might represent a new service, an old deployment or incomplete tagging. Record the unresolved question before escalating it as unauthorised use.

Keep activation and reporting delays visible

AWS Billing's IAM-principal guidance says Bedrock tags appear for activation after the tagged principal makes an API call. Tag keys can take up to 24 hours to appear, followed by up to 24 hours to activate.

Cost Explorer refreshes at least once every 24 hours, with some data arriving later. A recent configuration change and a quiet report can coexist. Set an observation window that accounts for the documented stages and preserves unresolved data.

The Bedrock pages describe allocation tags as applying after activation. AWS Billing separately documents up to twelve months of backfill for eligible resource tags that existed historically. Applicability to IAM-principal or session tags remains unverified here; confirm the exact tag type before promising historical attribution.

Review usage alongside net cost

Cost Explorer charge-type filters distinguish charges, credits and refunds. AWS credits apply to eligible services according to their terms. Review the relevant usage and charge records as well as a net-cost total, without assuming any particular model qualifies for credits.

Billing also leaves prompt contents and execution outcomes outside this discovery record. Bedrock invocation logging is a separate configuration and is disabled by default. Enabling additional content collection needs its own security and privacy review.

Use complementary evidence for the remaining questions. Azure resource inventory identifies configured resources in another cloud, while DNS evidence records a different part of the network path. Keep each source's scope and delay explicit.

A useful discovery handoff names the account, application owner, evidence window, approval status and missing fields. Track how many leads receive an owner and a resolved disposition, with unknowns retained. These are documentation-led criteria; no customer billing account was queried and no employee activity was observed for this guide.

Map your AI discovery coverage with Promptective.