A courts docket-summarization agent needs to let a third-party vendor's external system call it, and the office must decide which credential mechanism fits that integration. Which choice is the better fit?
Select an answer to reveal the explanation.
Short Explanation
An external vendor isn't a coworker with a company badge — they're a guest, and a Bedrock API key is the visitor pass built for exactly that relationship. Save the AWS-native role credentials for services that already live inside the account. Different caller, different credential.
Full Explanation
A third-party vendor's system is an external caller outside the office's own AWS account and identity boundary, which is the scenario a Bedrock API key is built for — it gives the vendor a credential scoped to Bedrock access without requiring them to hold AWS account credentials or assume a role inside an account they don't belong to. Having the vendor's system directly assume an IAM role is the pattern for first-party or cross-account AWS-to-AWS access with an established trust relationship, not a general mechanism every external caller can use, and setting it up for a simple vendor integration adds unnecessary complexity. Sharing root account credentials is a severe security anti-pattern regardless of the integration type — root credentials are never intended to be distributed to any party, internal or external. Accepting unauthenticated requests removes any control over who can invoke the agent at all, which fails the basic requirement of a controlled third-party integration. Scope caveat: whichever credential mechanism is chosen, scope its permissions to only the docket-summarization actions the vendor integration requires, and set an expiration or rotation plan for the credential. Operational check: confirm the vendor's requests are rejected once the issued credential is deliberately revoked, verifying the access control is actually enforced.