Built a bot for our support team. It's not a gimmick. It's a controlled, scoped tool that directly cut ticket volume by 15% in the first month. The key was not making it "smart," but making it secure and limited.
Most teams give their bot full API access "to fetch user data." That's a disaster. Ours uses a strict IAM role with zero trust principles.
* The Poe bot runtime role can only assume a specific support-API role.
* That support-API role has permissions scoped to `GET` methods only on the `/api/user/{userId}` endpoint.
* Conditional policy enforces the bot can only request data for the `userId` extracted from the conversation context (no arbitrary lookups).
* All prompts are pre-reviewed to avoid injection or data leakage patterns.
Example of the trust boundary:
```json
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::*:role/support-readonly-api",
"Condition": {
"StringEquals": {"sts:ExternalId": "poe-bot-runtime-identifier"}
}
}
```
The bot answers common, repetitive account status and billing questions by pulling only the necessary user context. It deflects anything else immediately to a human. No hallucinations, because its knowledge is locked down. This is about reducing attack surface, not just tickets.
Least privilege is not a suggestion.