Support Portal by Altores implements a layered abuse prevention model that addresses distinct classes of platform misuse across multiple system layers. Controls are applied independently at the infrastructure level, the application layer, the AI execution pipeline, and the client account level, ensuring that protections remain effective regardless of the channel or access pattern involved.
1. Web traffic protection
Relevant public-facing HTTP endpoints are protected by request throttling applied per client IP address. These controls mitigate brute-force attacks, automated scraping, and denial-of-service attempts against the platform.
| Endpoint category | Protection applied |
|---|---|
| Global requests | IP-based rate limiting across all relevant public endpoints |
| Widget interactions | Limits on conversation creation, session creation, and contact updates |
| Authentication | Rate limits applied to login attempts, password resets, account registration, and MFA verification |
| File uploads | Request limits protecting storage and bandwidth resources |
| Transcript export | Limits preventing excessive data extraction |
| Contact search | Limits preventing automated scraping |
| Reporting endpoints | Request limits protecting analytical workloads |
All limits are configurable through configuration settings at the account-level and at platform level by direct request to the Altores Team.
Trusted IP addresses may be safelisted where appropriate (for example, for internal networks or monitoring services).
Throttle events are logged with relevant request metadata to support operational monitoring and security auditing.
2. Messaging channel protection
For messaging channels such as WhatsApp, inbound traffic is received through provider webhooks. Because the originating IP address belongs to the provider infrastructure rather than the end user, IP-based throttling is not applicable for per-user abuse prevention in these channels.
Rate limiting is instead enforced at the application layer using internal identifiers, specifically contact ID, conversation ID, and AgentBot identifier.
Contact-level and conversation-level AI rate limits
Before an automated AI response is generated, the system evaluates whether the contact or conversation has exceeded configured activity thresholds. If the configured limit is reached, automated responses are temporarily suppressed and the user receives a feedback message indicating that requests should be retried later.
This prevents individual users from repeatedly triggering automated responses at an excessive rate, regardless of the channel they are communicating through.
3. AI agent execution layer
In addition to application-level protections, rate limiting is enforced within the AI agent execution layer responsible for generating automated responses.
Per-bot rate limiting
Each AI bot can be configured with activity limits governing how frequently it processes requests across users and conversations. When these thresholds are exceeded, the system temporarily rejects additional automated response requests and returns a configurable feedback message to the affected user.
This protects the AI execution pipeline from excessive request volume originating from any single bot assignment.
Client-level AI response quota
Each client account is allocated a defined allowance of automated AI responses within a billing period per their contract. The system tracks:
- Allocated response capacity
- Consumed automated responses
- Remaining capacity
When the included allocation is reached, usage transitions to pay-as-you-go billing by default, allowing automated responses to continue without service interruption. Alternatively, if requested by the client, automated responses can be configured to pause once the allocation is fully consumed.
This provides transparent usage tracking and ensures fair resource allocation across client tenants.
4. Configuration
All protections described in this article are configurable within predefined safe ranges through configuration settings in Support Portal or by direct request to Altores. Specific limit values and thresholds are agreed upon at the account level.
5. Layered abuse prevention model
Each protection layer operates independently and addresses a distinct part of the system:
| Layer | Scope | What it protects against |
|---|---|---|
| IP protection | Public HTTP endpoints | Infrastructure abuse, brute-force, scraping |
| Contact-level AI limits | Messaging channels (per contact / conversation) | Repeated automated response triggering by individual users |
| Conversation flood protection | Conversation level | Message spam within individual conversations |
| AI bot execution limits | AI processing pipeline | Excessive request volume per bot |
| Client-level usage quotas | Account level | Unfair consumption of automated response capacity across tenants |
Together, these layers provide a model that protects the platform while maintaining reliable service for legitimate users. No single protection is expected to operate in isolation, the combination of controls is designed to address the full range of abuse vectors relevant to a multi-tenant conversational operations platform.