The short answer

AWS has made an important change to Amazon Bedrock AgentCore Identity: AI agents can now reference existing secrets in AWS Secrets Manager for outbound authentication, instead of relying only on secrets created automatically by AgentCore.

For enterprise teams, this is not just a convenience feature. It is a governance signal. AI agents are moving from experiments into production workflows, and production workflows need proper identity, access control, encryption, auditability, rotation, and ownership.

An AI agent that can act on business systems is no longer a chatbot. It is an operational identity with decision-making capacity.

That distinction changes everything.

Why secrets become a bottleneck in agentic AI

Most organizations first meet AI through content generation, analysis, summarization, or search. Those use cases are valuable, but they usually live inside a contained environment. Agentic AI is different.

A useful enterprise agent needs to do things. It may read a customer record from a CRM, create a GitHub issue, update a support ticket, send a Slack message, trigger an approval flow, call an internal API, or retrieve data from a finance system.

Each of these actions requires some form of trust:

  • API keys
  • OAuth client secrets
  • Service credentials
  • Resource permissions
  • Runtime identity
  • Audit trails

This is where many agent projects slow down. The model may work. The demo may impress leadership. The workflow may show a strong business case. But the security team asks a simple question: where are the credentials, who can access them, how are they rotated, and how do we prove it?

If the answer is unclear, the project should not go to production.

What changed in Amazon Bedrock AgentCore Identity

Previously, when an outbound authorization provider was configured in AgentCore Identity, the service could create a dedicated secret in AWS Secrets Manager and store the required API key or OAuth client secret there. That solved the basic implementation problem, but it did not fully satisfy organizations with established secrets management standards.

Large enterprises often need to define these controls themselves:

  • Customer-managed KMS encryption keys
  • Rotation policies
  • Tagging for cost allocation and compliance
  • Replication rules
  • Resource-level access policies
  • Cross-account security patterns
  • Centralized audit and monitoring

The new capability allows teams to provide AgentCore with the ARN of an existing secret and the key name inside the JSON structure that contains the sensitive value. At runtime, AgentCore Identity retrieves the current value from Secrets Manager.

That means the agent can use the same security infrastructure already used by production applications.

A simplified conceptual configuration may look like this:

{
  "secretArn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod-agent-salesforce",
  "secretKey": "clientSecret"
}

If the security team rotates the secret, the agent does not need to be rebuilt. The authorization provider does not need to be recreated. The agent simply receives the current value during runtime access, according to the permissions granted to it.

That is the kind of operational detail that separates a prototype from an enterprise system.

The business meaning: AI agents are entering the governance perimeter

The real story is not Secrets Manager. The real story is that autonomous and semi-autonomous AI workloads are being pulled into the same governance perimeter as normal software.

This matters for finance, healthcare, insurance, government, defense, retail, and any organization where a system action can create financial, legal, operational, or reputational exposure.

When agents act on behalf of employees or business processes, enterprises need a model that answers practical questions:

  • Which agent performed the action?
  • Which system did it access?
  • Which credential did it use?
  • Was the credential rotated according to policy?
  • Was the secret encrypted with the required KMS key?
  • Could the agent access only what it needed?
  • Can we revoke access without breaking unrelated workloads?
  • Can internal audit reconstruct the event?

Without these answers, agentic AI remains a lab exercise.

With these answers, it becomes a manageable operational capability.

AI is not only a technical implementation

One of the mistakes organizations make with AI agents is treating them as a technical integration project. They are not. They sit at the intersection of AI, business process design, security architecture, risk management, and organizational change.

The technical pattern matters, but it is not enough. A stable agent implementation requires deep understanding of the business process being automated. It also requires judgment about where autonomy creates value and where human review remains necessary.

Human-in-the-loop is still critical. But if every agent action requires a human to approve every step, the organization has not gained much. The better question is how one skilled employee can supervise hundreds of agent-driven processes instead of manually executing one process at a time.

That shift requires careful design:

  • Agents should have narrow permissions.
  • High-risk actions should require explicit approval.
  • Low-risk repetitive actions should be automated where possible.
  • Exceptions should be routed to humans with context.
  • Logs should be readable by both technical and business owners.
  • Performance should be measured against process outcomes, not model novelty.

This is why serious AI adoption cannot be led by tool enthusiasm alone. It needs professional depth, business experience, and security maturity.

What security teams should do now

Organizations building on Amazon Bedrock should treat this update as an opportunity to standardize agent security before usage spreads informally.

A practical starting point is to define a policy for agent credentials:

  1. Use existing AWS Secrets Manager secrets where possible.
  2. Encrypt sensitive secrets with customer-managed KMS keys when required.
  3. Grant secretsmanager:GetSecretValue only to the specific runtime identity that needs it.
  4. Grant kms:Decrypt only when the identity must decrypt a customer-managed key.
  5. Use resource-level IAM conditions where appropriate.
  6. Tag secrets by environment, owner, business process, and compliance domain.
  7. Rotate credentials through the central security process, not through ad hoc agent configuration.
  8. Monitor secret access patterns and alert on unusual usage.

This is also the right time to define an internal ownership model. Every agent should have a business owner, a technical owner, an approved permission scope, and a retirement process.

In the future, information systems departments will increasingly resemble human resources departments for AI agents. They will onboard agents, assign permissions, monitor performance, manage incidents, revoke access, and decide when an agent should be retired or redesigned.

That may sound unusual today. It will feel normal sooner than many executives expect.

Why this matters beyond AWS

Although this update is specific to Amazon Bedrock AgentCore Identity, the principle applies to every enterprise AI platform.

Whether an organization uses AWS Bedrock, Microsoft Copilot Studio, Claude-based workflows, n8n automations, internal orchestration frameworks, or a combination of tools, the same rule applies: agents must not become a shadow identity layer.

The enterprise needs a reliable platform for creating, managing, securing, observing, and retiring agents. It also needs AI literacy across the workforce, because employees must know how to communicate effectively with models and when to escalate to human judgment.

There are two adoption tracks that should move together:

  • Broad AI literacy for employees and managers.
  • Internal capability to build and govern AI agents.

Many companies focus only on the first track because it feels easier. Others jump directly into agents without preparing the organization. Both approaches are incomplete. The real advantage comes from combining workforce literacy with controlled agent infrastructure.

The finance angle: control lowers the cost of scaling

From a finance perspective, this kind of security improvement has a direct impact on AI scalability.

Poor secrets management increases hidden costs. It creates duplicated work, manual credential rotation, audit friction, delayed production releases, and incident risk. These costs rarely appear in the original AI business case, but they show up later in engineering time, compliance reviews, and operational delays.

Using existing secrets infrastructure reduces that drag. It allows cloud, security, and platform teams to reuse established controls rather than creating exceptions for AI workloads.

That matters because exceptions are expensive. They require special approvals, custom documentation, unique monitoring, and ongoing operational attention. A scalable AI program cannot survive on exceptions.

The deeper lesson

This AWS update is a small interface change with a large strategic message: enterprise AI agents must inherit enterprise controls.

The organizations that succeed with agentic AI will not be the ones that run the most exciting demos. They will be the ones that combine strong AI capability with disciplined process design, security architecture, operational governance, and experienced business judgment.

AI can create significant operational efficiency, especially in processes that require judgment rather than deterministic rules. But autonomy without control is not transformation. It is unmanaged risk.

Securing secrets properly is one of the foundations of trust. And trust is what allows agents to move from proof of concept to real business execution.