What did AWS publish?
In its technical walkthrough, AWS extends an earlier example that used one agent and two Model Context Protocol (MCP) servers. The new design adds Amazon Bedrock AgentCore Gateway to handle access to tools and exchange delegated credentials for each target. Policy in Amazon Bedrock AgentCore checks Cedar policies before tool discovery and execution.
AWS also demonstrates a second agent running on Amazon Elastic Kubernetes Service (Amazon EKS). Each agent has its own Okta identity, Gateway, and credential provider. Amazon Bedrock AgentCore Observability and Amazon CloudWatch bring together traces, while Okta’s System Log supplies records of delegated access. This is an implementation walkthrough, not a ready-to-deploy business application.
What does this mean for a smaller business?
The useful distinction is between an employee’s permissions and an agent’s permissions. An employee may be authorised to change a record, but a reporting agent acting for that employee should not automatically receive the same power. AWS demonstrates this separation with a reporting agent restricted to read access.
For a small or medium business, this suggests defining access by job rather than giving every assistant broad credentials. A reporting worker might read information; a task-management worker might make approved changes. The design also keeps checks at the tool server, where the user’s groups and delegated scope still matter. A gateway permission is not the only decision.
What should managers check before approving a pilot?
Start with evidence of both allowed and blocked actions. AWS describes traces that connect agent activity, identity checks, policy decisions, and the tool server’s response. Ask your technical team to demonstrate that a forbidden change is rejected, not merely that an ordinary request succeeds. Also check whether the records identify the user, agent, action, and reason for the decision.
Treat implementation effort and operating cost as separate questions. AWS says the additions take about 90 minutes, but it also states that the snippets are conceptual rather than a complete deployable solution. The sample code is for non-production use. AWS advises involving security and legal teams before deployment. The walkthrough also identifies infrastructure charges and usage-based charges, so do not treat the setup estimate as a production budget.
What practical steps should you take next?
Choose one narrow workflow and list the tools it needs. Separate reading from changing data, and record which users may authorise each action. Start the pilot with only the permissions that workflow requires. Before expanding it, test the wrong agent, insufficient permissions, and a user who should be refused.
Assign someone to review access decisions and approve permission changes. Ask your implementation team to show where credentials are exchanged, where requests can be blocked, and how a failed request is investigated. Do not assume that adding more agents means they should all share the same identity or access rules.
For a broader digital-worker evaluation, Terabot gives businesses AI workers with their own computers, each a private virtual machine, working in the apps a team already uses and around the clock. It is in private preview by invitation only. Apply the same workflow, permission, and evidence questions when assessing any digital worker.
Key takeaways
- AWS demonstrates separate controls for the agent’s identity, its delegated scope, and the user’s authority.
- A useful pilot must prove that unauthorised actions are blocked and that decisions can be investigated.
- Start with one workflow and limited permissions; assess production readiness and costs separately from setup time.
Written with AI assistance from the source linked above, and checked against it before publishing. Product names belong to their owners. Check the original source before relying on details.