How Amazon Connect Secures Credentials for Its AI Agents

"Amazon Connect Vaults" is not a real product

A search for a vault inside Amazon Connect turns up nothing, because AWS has never shipped a feature by that name. What you are actually looking for is how Amazon Connect keeps a credential away from the people and code that don't need it, and that job is split across three existing AWS services rather than bundled into one branded vault.

Worth knowing first: the product itself changed name. AWS's documentation now states plainly that "Amazon Connect Customer is the current name for the product previously called Amazon Connect," and that Amazon Connect is now the umbrella brand for a set of agentic AI solutions across different business functions. This guide uses "Amazon Connect" the way almost everyone still searches for it, meaning the contact center product, and notes the official name where it matters.

So the honest answer to "amazon connect vault" is that the protection you want already exists, under three names you can actually go read documentation for: AWS IAM, Lambda resource-based policies, and AWS Secrets Manager.

• No AWS service or feature is named "Amazon Connect Vault."
• The contact center product's current official name is Amazon Connect Customer.
• Credential protection is IAM plus Secrets Manager, not a single bundled tool.

What Amazon Connect's AI agents are, as of 2026

Amazon Connect's AI capabilities now split into two groups. One group acts on its own: Agentic Self-Service resolves a customer's issue end to end across voice and chat, reasoning across your systems and taking action such as processing a return, and Agentic Voices provides the natural-sounding, turn-taking voice layer behind it across more than fifty languages. The other group assists a human agent instead of replacing one: Agent Assist detects what the customer needs mid-conversation and recommends a response, and Manager Assist (still in preview) surfaces operational insights from contact center metrics.

Amazon Q in Connect, the generative assistant AWS introduced for customer service reps, has been folded into this same family. AWS's own documentation now describes it as simply one of the AI agents under the broader Connect umbrella, and says the platform supports multiple configurable agents, the Model Context Protocol for connecting agents to external tools, and agent-to-agent handoffs.

Every one of these features, autonomous or assistive, still runs inside your AWS account on your Connect instance. None of it is a separate vendor holding your credentials; it's AWS code calling AWS and non-AWS APIs on your behalf, under the permissions you grant it.

• Agentic Self-Service and Agentic Voices act without a human agent present.
• Agent Assist and Manager Assist support a human agent; they don't replace one.
• Amazon Q in Connect is now one of several configurable AI agents, with Model Context Protocol support for connecting to external tools.

IAM decides what an agent, or the code behind it, can touch

Access to Amazon Connect resources is controlled the same way as any other AWS service: through IAM identity-based policies attached to users and roles, and resource-based policies attached to the resource itself. An administrator writes a policy that says which principal can take which action on which resource, and AWS evaluates that policy on every single call. There is no path around it, including for AI agents acting inside a flow.

The clearest example is how a contact flow invokes AWS Lambda, which is how almost every AI agent inside Amazon Connect reaches your own systems. When you add a Lambda function through the Connect console, Connect attaches a resource-based policy to that function automatically, naming connect.amazonaws.com as the allowed principal and your Connect instance's ARN as the allowed source. If the function lives in another account or region, you add that same policy yourself with the Lambda add-permission CLI command. Either way, the function can only be invoked by your specific instance, not by anyone else's Connect account and not by a copied ARN someone found in a support forum.

That source-ARN check is exactly the fix for what security researchers call the confused deputy problem: a function with real permissions getting tricked into acting on behalf of an identity it shouldn't trust. Connect's Lambda integration is built to avoid it by design, not as an afterthought.

• IAM policies name a principal, an action and a resource; every Connect API call is checked against them.
• Connect's resource-based policy on a Lambda function restricts invocation to your own instance's ARN.
• Cross-account or cross-region functions need that permission added manually with Lambda's add-permission call.

Where the actual secret lives: AWS Secrets Manager

IAM controls who can call what. It is not where you put a password, an API key or an OAuth token for a system outside AWS, such as the CRM an Agentic Self-Service flow checks before refunding an order. That's AWS Secrets Manager's job, and AWS's own guidance is direct about the boundary: use Secrets Manager for database and application credentials, API keys and OAuth tokens; use IAM itself for AWS credentials; use AWS KMS for encryption keys.

The pattern in practice: your Lambda function, the one Connect's resource policy lets the instance invoke, calls the Secrets Manager API at runtime to retrieve the value it needs, using the permissions on its own execution role. The secret never sits in the flow definition, never sits in the Lambda's environment variables as plain text, and never shows up in a CloudWatch log unless your code prints it. You can turn on automatic rotation, which swaps the secret on a schedule using a small Lambda function Secrets Manager runs for you, so a credential that's a year old today doesn't stay that way.

This is the real, checkable version of "vault": a service built specifically to stop you hardcoding a credential into source, paired with an execution role that only your function can assume.

• Secrets Manager is for application and API credentials, OAuth tokens and database passwords.
• AWS recommends IAM itself for AWS credentials, not Secrets Manager.
• A secret is fetched at runtime by the Lambda's own execution role, never stored in the flow.

The pattern end to end

Put together, a credential-safe AI agent flow in Amazon Connect looks like this: a contact flow invokes a Lambda function, Connect's resource-based policy proves the call really came from your instance, the Lambda's execution role (an IAM role, scoped to only what that function needs) is what the function runs as, and if the function needs to reach something outside AWS, it calls Secrets Manager's GetSecretValue API at that moment rather than reading a stored value.

Nothing in that chain is Connect-specific wizardry. It's the same identity and secrets architecture AWS recommends for any serverless application, applied to a contact center flow instead of a web API. That's good news if you already run other Lambda-backed systems: the skills transfer directly, and so does the review checklist.

• Contact flow invokes Lambda, gated by a resource-based policy scoped to your instance's ARN.
• Lambda executes under its own least-privilege IAM role.
• Any external credential is fetched from Secrets Manager at call time, not stored in the flow or the function.

What this doesn't cover

This architecture protects AWS-side credentials and the secrets you deliberately put in Secrets Manager. It says nothing about what the newest agentic features do with a tool credential once Model Context Protocol support is in general use for building Connect agents; AWS's documentation confirms MCP is supported but doesn't yet spell out a credential pattern specific to it, so treat that as an open question rather than a solved one.

It also doesn't make a bad IAM policy safe. A Lambda execution role with excess permissions, or a resource-based policy copied from a tutorial without checking the source ARN, defeats all of this. The mechanism is only as good as the policy you actually write.

• MCP-based tool credentials for Connect's agents aren't yet documented as a specific pattern; verify before relying on one.
• An overly broad IAM role or a miscopied resource policy undoes the protection described here.

What's true on your own machine, and where Forkbench fits

None of the above runs on your laptop. It runs inside your AWS account, enforced by AWS. The part that does happen on a developer's machine is the AWS credentials and any third-party API keys you use locally while building or testing the Lambda functions these flows call, and that part has nothing AWS-specific about how it should be handled: don't put it in a .env file an editor or a coding agent can read, and don't paste it into a chat.

Forkbench is a desktop app for the Mac that runs coding agents in a terminal. Its Vault keeps a secret in your Keychain and lets a command use it by name, so an AWS access key or a third-party API key you're testing with never has to sit in a file or appear in a prompt. Forkbench has no integration with AWS, Amazon Connect or any of its AI agent features; it only manages what's on your own Mac while you write the code those flows eventually run in the cloud. An unpinned Vault key can still be read by the program it's handed to once that program runs, same as any secret.

• Everything in this guide runs inside AWS, enforced by AWS, not on a developer's laptop.
• Local AWS credentials and test API keys still need the same hygiene as any other secret.
• Forkbench's Vault protects secrets on your Mac; it has no AWS or Amazon Connect integration.