Swif.ai provides powerful device management actions for company‑owned assets—such as remote erase, user removal, and soft wipe. Because these actions are highly sensitive, we’ve implemented multiple layers of protection to keep your organization safe and prevent abuse or mistakes.
This article explains, in plain language, how Swif.ai protects these key APIs and what that means for your team.
1. Which APIs Are Protected?
Swif.ai applies enhanced guardrails to “high‑impact” device commands, including:
Remotely erases a device.
Removes users from a device.
Performs a soft wipe of a device.
System commands executed via webhook (for automated actions triggered from other systems).
These endpoints can make irreversible changes to company assets. They’re treated as critical operations and are never exposed without safeguards.
2. BYOD vs. Company‑Owned: Hard Separation
Swif.ai clearly distinguishes between:
Company‑owned devices: Devices fully managed by your organization via Swif.ai MDM.
BYOD (Bring Your Own Device): Personally‑owned devices enrolled under user‑friendly or lightweight control.
To protect employee privacy and prevent overreach, Swif.ai does not allow destructive or intrusive commands to run against BYOD devices, even if they are technically enrolled.
What this means in practice
For BYOD devices:
Calls to the critical APIs above are rejected immediately.
No command is queued for the device.
The device is not erased, wiped, or modified via these APIs.
Result:
The request is rejected at the API layer.
No destructive action is sent to a BYOD device.
This same behavior applies to:
erase-devicedelete-userssoft-wipeProtected system commands via webhook
Bottom line: High‑impact actions are limited to company‑owned assets only. BYOD devices are explicitly shielded from these commands.
3. Rate‑Limiting Guardrails for Critical APIs
Even on company‑owned devices, Swif.ai protects your environment from sudden bursts of requests that may be caused by:
Automation bugs
Misconfigured scripts
Malicious scripts or credential abuse
To handle this, Swif.ai implements per‑IP, time‑window rate limiters on protected APIs.
Per‑IP protection window
For each IP address calling a protected endpoint, Swif.ai tracks usage in a short rolling window (for example, 5 seconds). Within that window:
Stage 1 – Warning threshold (5 requests / 5 seconds)
When more than 5 requests are received from the same IP within the window:
Swif.ai triggers an asynchronous Slack alert to the internal team.
This provides early visibility into suspicious spikes.
Requests may still succeed at this point, but they are now being closely monitored.
Stage 2 – Blocking threshold (10 requests / 5 seconds)
When more than 10 requests are received from the same IP within the same window:
Swif.ai returns HTTP 429 Too Many Requests.
Additional calls from that IP to the protected API are temporarily blocked.
This “hard stop” protects:
Devices from repeated destructive commands
Your infrastructure from abuse
Your organization from accidental or scripted mass operations
In other words, the system behaves similarly to modern communications APIs that automatically detect and throttle abnormal usage patterns.
4. Example: How the Guardrail Behaves
On a company‑owned device, you can see the guardrail behavior by rapidly calling a protected endpoint like soft-wipe:
The first few requests succeed (normal operation).
Around request #6, the warning limiter is triggered:
Internal teams receive a Slack notification about unusual traffic.
By around request #11, the blocking limiter activates:
The API returns 429 Too Many Requests.
Further requests from that IP in the window are rejected.
This protects your environment from any abnormal, non‑human request rates.
5. Agent‑Side Safeguards Against Infinite Loops
In addition to server‑side guardrails, Swif.ai also implements agent‑level protections so devices behave safely even when they encounter unexpected responses.
For example, if an agent repeatedly receives a negative or error response from a critical backend API (such as the MQTT credential endpoint), Swif.ai’s agents:
Detect suspicious repeated failures.
Can temporarily block further high‑impact requests from that agent for a cooldown period (for example, an hour).
Prevent infinite request loops that could:
Hammer the backend
Spam critical endpoints
Generate unnecessary actions
This “defense in depth” model ensures that even if a misbehaving agent or network issue appears, both the server and the agent cooperate to contain the impact.
6. Summary: Defense in Depth for Sensitive Actions
Swif.ai’s approach to protecting key device management APIs includes:
Scope Control
Destructive commands are limited to company‑owned devices only.
BYOD devices are explicitly shielded and will reject critical actions.
Rate‑Limiting & Anomaly Detection
Per‑IP thresholds within short time windows.
Warning stage with Slack alerts (visibility without immediate disruption).
Blocking stage with 429 responses (hard stop for suspicious surges).
Agent‑Level Protection
Agents avoid infinite loops against backend APIs.
High‑risk agents can be temporarily blocked if they misbehave.
Consistent Enforcement
Guardrails are implemented as reusable middleware and shared logic across Swif.ai’s MDM services, so behavior is consistent wherever these critical APIs are exposed.