AWS AgentCore for Teams and Slack: Permission, Session and Security Risks

What the report proposes​

TechGig describes an AI agent that lives in an existing team channel and acts like a colleague. The agent sees questions in context and its answers are visible to everyone. It hands work to a human owner when it reaches its limits.

The AWS building blocks it names are:

• Amazon Bedrock AgentCore Runtime, which hosts the agent with session isolation. The report says it supports frameworks such as Strands Agents and LangGraph.
• Bedrock Knowledge Bases, which hold product documentation and past decisions for grounding.
• Bedrock Guardrails, which keep the agent on topic and filter sensitive data.
• AgentCore Gateway, which exposes internal APIs as tools scoped to the agent's role.
• API Gateway, Lambda and SQS, which connect the chat platform to the agent.

The report also claims that users address the agent with @mentions and reactions. It says the same agent can be swapped between Teams and Slack, and that the agent acts with the asker's permissions rather than its own elevated rights.

What AWS documents​

Several of these claims have documented support. Others are the report's own.

The Slack pattern is documented. An AWS Machine Learning blog post on integrating AgentCore with Slack uses Amazon API Gateway, AWS Lambda, AWS Secrets Manager and Amazon SQS for serverless integration. The agent is containerized and hosted to run in AgentCore Runtime. A matching write-up says the design derives session IDs from Slack thread timestamps and uses SQS to handle Slack's 3-second webhook timeout. That explains why SQS appears in the architecture: Slack expects a quick acknowledgment, and an LLM-backed agent is rarely that fast.

Teams has a sample pattern too. An AWS sample repository describes a bot handler on API Gateway and Lambda that calls an AgentCore Runtime endpoint. Per that sample, the endpoint is callable via POST /invocations with JWT Bearer authentication. It covers both Teams and Slack, but it is a sample project. It is not a managed Teams product.

AWS also offers a managed route. AWS Chatbot enables customers to interact with Amazon Bedrock agents from Slack and Microsoft Teams chat channels. This was announced in 2024 and applies to Bedrock Agents. Channel members start using the agent by tagging it. That is a simpler path if you don't need a custom bot, though it is a different mechanism from the AgentCore architecture the report describes.

AgentCore Gateway can talk to Teams through Microsoft Graph. AWS's developer guide lists Microsoft and Slack among the integration-provider templates you can add as Gateway targets. For Teams, the documented server URL is Microsoft Graph at [url]https://graph.microsoft.com/v1.0[/url]. The listed operations include:

• listing and creating chats, and sending chat messages
• listing teams, channels and members
• sending and replying to channel messages
• creating online meetings and listing their recordings and transcripts

This path is for the agent calling Teams as a tool. It is not the path that lets people chat with the agent inside Teams.

Limits to plan around​

AWS's documentation sets several boundaries that the report doesn't mention:

• Provider templates can be added as Gateway targets only through the AWS Management Console, not through the API.
• AgentCore doesn't host the integration server. You must set up hosting yourself.
• The templates cover only a subset of each provider's APIs. AWS suggests checking the provider's own documentation and sending a tools/list call to the configured target to see what's actually exposed.
• The documented outbound authentication type for the Teams template is an API key.

The permissions claim needs scrutiny​

The report says agents act with the permissions of the person asking. That is a sound principle, but nothing in the sources shows it comes automatically with this architecture. A Teams deployment involves at least three identities:

1. The person typing in Teams.
2. The identity the integration uses to authenticate to Microsoft Graph.
3. The AWS execution role the agent runs under.

An API-key template is not the same as per-user delegated access. If a shared credential sits behind the connector, the agent may see far more than the person asking is entitled to see. This is my inference from the gap between the report's claim and the documented authentication model. It is not evidence that any particular deployment is insecure. Delegating user permissions has to be designed in deliberately.

AWS's IAM guidance for AgentCore Runtime backs this up. The managed BedrockAgentCoreFullAccess policy includes GetWorkloadAccessTokenForUserId. AWS says that action lets a caller issue workload access tokens from a user identifier string without verification by an identity provider. For production, where your application has JWTs, AWS recommends explicitly denying that action and granting only GetWorkloadAccessTokenForJWT. AWS also warns that IAM policies generated by the AgentCore CLI are meant for development and testing, not production.

AWS has also written about Policy in AgentCore, a deterministic layer that enforces identity-aware controls so agents only reach tools and data their users are authorized to use. That is one way to turn "least privilege" from a slogan into a control.

The shared-connector session risk​

One more caveat matters for any Teams or Slack bot serving many people. AWS's runtime security documentation says invocation is authorized against the runtime resource ARN, not against individual sessions. The runtime checks the session ID's format but not whether the caller owns that session. If one backend principal invokes the agent for many end users, your application must bind each user to the right session ID. Otherwise a user who can supply another user's session ID could potentially route a request into that session. AWS recommends application-level session-to-user binding, CloudTrail auditing and, where practical, separate per-user or per-tenant principals.

A shared chat connector is exactly this multi-user setup, so the risk applies directly.

A practical checklist for IT teams​

1. Inventory the actions. List the exact Graph or Slack operations the agent needs. Don't enable broad scopes "just in case."
2. Pick the integration path. AWS Chatbot is the managed route for Bedrock Agents. A custom bot with API Gateway, Lambda, SQS and AgentCore Runtime gives you more control and more work.
3. Authenticate users. Decide how the person's identity reaches the agent, and use JWT-based tokens rather than caller-supplied user IDs in production.
4. Replace development policies. Swap the CLI-generated and full-access policies for custom least-privilege ones.
5. Bind sessions to users. Enforce this in your own code and audit with CloudTrail.
6. Test what the agent can see. Check which messages, channel context and credentials actually reach the agent. Visibility depends on the API permissions you grant, not on where the agent is hosted.
7. Plan the human handoff. The report calls handovers natural. In the sources reviewed here, that behavior is something you design. No documented feature delivers it automatically.

What isn't established​

• The report's claim that serverless glue eliminates idle costs is not backed by the AWS documentation reviewed here. Don't treat it as a guaranteed saving.
• @mention and reaction behavior in Teams, and automatic human handoff, are described by TechGig but not shown as built-in features of the AgentCore Gateway template.
• No tested implementation, customer deployment or benchmark accompanies the report.

Bottom line​

Running an agent on AWS and exposing it in Teams or Slack is feasible, and AWS documents patterns for it, especially for Slack. Whether it is safe depends on identity design, scoped tools and session handling, none of which the architecture diagram gives you for free. Treat the report as a map of the components and AWS's own security guidance as the part that decides whether the deployment is safe to run.