Three layers of permission behind every tool call
Your configuration, your user's authorization and the provider's own rules. How Agent200 decides whether a tool may run, and the controls underneath.
2 min read
Giving an agent access to the outside world raises a fair question: what stops it from doing something it should not? On Agent200 the answer is three independent layers, each owned by a different party, and a tool runs only when all three allow it.
Layer one: what your application may do
You choose the services your agent can reach, the endpoints it can call within each, and the OAuth scopes it requests. A read-only setup might look like this:
Chat ✓ Search messages ✓ Retrieve messages ✗ Send messages ✗ Delete messages Email ✓ Read emails ✗ Send emails ✗ Delete emails
Anything you leave off is never exposed to the model as a tool, and never executed. Set it per project and per workflow, down to the individual operation.
Layer two: what your user allowed
Your configuration says what your application may ask for. Each end user then decides what to grant, on the provider’s own consent screen, for their own account. If a user never connected a service, no tool can reach it on their behalf.
Layer three: what the provider enforces
The external service has the last word. Its API enforces the scopes it granted and its own rules. Agent200 cannot open anything the provider has not authorized, and does not try to.
One user never sees another’s data
Connections are mapped to individual end users inside your project. A request made for one user runs on that user’s connections only. Users only see data already authorized in the source systems.
The controls underneath
Agent200 operates under the same certifications and measures listed on the Security page:
- SOC 2 Type II and GDPR.
- AES-256 encryption. All data is encrypted at rest using a FIPS 140-2 validated crypto module, and all data in transit uses TLS 1.3+.
- Zero data retention. Your queries and responses are processed in real time and never stored.
- Zero LLM training. Your data is never used to train AI models.
- AES-256 per-user encryption. Every user’s data is encrypted with individual keys, not just tenant-level isolation.
Need the details for a security review? See the Security page, or request the SOC 2 Type II report.
