Does the deployment have to be in the cloud?
No. On-prem deployment is supported. Fully disconnected (air-gap) operation is supported as well — the platform can run on a network with no outbound connectivity at all.
01
Data residency and data flow
The first question in any enterprise review is always the same: where does the data go? The answer is given at the architecture level, not as a promise.
What is the technical guarantee that data never leaves the machine?
In localOnly mode, cloud models never appear in the model list at all. If a cloud model is explicitly requested, the request is categorically rejected — no call is made. This is a runtime constraint, not a policy preference.
Who can see the cloud provider keys?
Provider keys stay on the platform administrator side and never reach the tenant space. They are always masked in the admin panel; no interface ever displays the clear value.
Can we run cloud and local models together?
Yes. Sensitive workloads can run on a local model and non-sensitive ones on cloud AI providers; the choice is defined per model and per agent. 17 AI providers are supported, and switching provider is a matter of configuration.
02
Multi-tenant isolation
When shared infrastructure is involved, the question is which layer enforces isolation. Isolation exists separately at the storage, encryption, integration, event distribution and authorization layers.
Where is usage and cost data kept?
In each tenant's own directory. There is no cross-tenant access — one tenant's usage records cannot be read from another tenant.
How are connection and provider keys stored?
Encrypted per tenant with AES-256. Nothing is stored in plain text.
Are integrations shared between tenants?
No. Integration connections are isolated per tenant; each customer organization sees and uses only the connections it has defined itself.
Can channel events leak into another tenant?
No. Channel event distribution is tenant-guarded; an event is delivered only to subscriptions belonging to its own tenant.
Are deployments cryptographically separated from one another?
Yes. Every customer deployment has its own RSA-2048 key pair. Entitlements travel in a signed manifest bound to that deployment; another deployment's manifest is not valid.
03
Authentication and access
The critical distinction: the enterprise authorization model applies not only to the user but to the AI as well. The AI cannot see data the user cannot see.
Can the AI see data it isn't authorized for?
No. Role-based access control and row-level security apply to the AI exactly as they do to the user. The AI operates within the authorization context of the requesting user.
How do we hide sensitive fields (salary, for example) from the AI?
Role-aware field filtering: the entity fields exposed to the AI are filtered by the user's role. The salary field is visible only to the HR role; for every other role the field is never passed to the model.
Can we restrict who is allowed to use an agent?
Yes. An allowed-role list can be defined per agent; roles outside that list cannot invoke the agent.
How are API keys protected?
API keys are stored as hashes — the clear value is never kept in the system. Rotation supports a transition window, plus IP allow-listing, per-minute rate limits and daily quotas.
Which authentication types are supported for outbound connections?
Six types: no auth, Basic, Bearer, API key, OAuth 2.0 (three flows) and Digest.
04
AI governance and guardrails
What the AI may do, what it may not do without approval, and how it is stopped are all set at the definition level.
What controls does model output pass through?
4 detectors + guardrail pipeline are active:
- Personal data (PII) detection
- Hallucination detection
- Prompt injection detection
- Cost limit
Are risky tools distinguished?
Yes. Tools carry a risk level — low, medium, high, critical — and may require approval according to that level.
How does the human approval flow work?
The approval flow has three states: pending → approved or rejected. Approval policy is defined per agent: which tools require approval, and the auto-approval timeout.
How do we stop the AI in an emergency?
Emergency stop (break-glass) is persistent: the stop survives a server restart and never lifts itself. Every autonomous operation is written to the audit log.
Can cost run out of control?
The cost limit is one of the guardrail detectors. Per-request, per-day and total cost ceilings are defined, and a notification is raised as a threshold is approached.
05
Audit and observability
Auditability is not a report bolted on afterwards — it is part of the runtime.
Can the audit log be altered after the fact?
The audit log is a hash-chained audit log; because records are chained to one another, any tampering breaks the chain and becomes detectable.
Are AI tool calls recorded?
Every MCP tool call is written to a daily JSONL file: timestamp, key identity, tool name, arguments, success status and duration. Fields such as passwords, tokens and keys are masked as they are written.
Can we see inside an AI run?
Yes. AI runs keep a trace: step-by-step records, tokens used, duration and cost. What happened at which step can be reviewed retrospectively.
Does it plug into our existing observability stack?
Yes. OpenTelemetry connects it to your existing tracing and metrics infrastructure; a separate console is not required.
Can personal data leak into logs?
Personal data masking and log scrubbing are applied; sensitive fields are masked at the logging layer before being written.
06
Network and attack surface
Giving the AI tools does not mean widening the attack surface — tool boundaries are enforced at runtime.
Can the AI send requests into our internal network?
No. The HTTP request tool has SSRF protection: calls to localhost, 127.0.0.1, ::1, 10.x, 172.16-31.x, 192.168.x and 169.254.x are blocked.
Can the AI modify the database?
Database tools are read-only. SELECT, WITH, SHOW, DESCRIBE and EXPLAIN are allowed; write and schema statements are blocked. More than 22 dangerous statements are blacklisted and SQL comments are stripped — which is how injection hidden inside a comment is prevented.
Can connection strings leak?
No. Connection strings are never exposed in API responses, in log records or to the AI.
Can we disable writes entirely during the evaluation?
Yes. The database manager has a read-only lock: while the lock is on, every mutating statement is rejected before it is ever sent.
How is the authenticity of outbound webhooks proven?
Webhooks are signed with HMAC; the receiving side verifies the signature and can prove the request genuinely came from the platform.
07
Compliance
What is the status on KVKK and certification?
KVKK (Turkish data protection law) compliance is in place. On the information security side there is an ISO 27001 certificate; the current list of documents is published on the security page.
What happens when a deletion request arrives?
A deletion request starts a 30-day undo window; after it expires, deterministic anonymization is applied — the record identity is dissociated irreversibly.
Does the audit trail meet enterprise expectations?
Enterprise logging and audit trail are standard; who accessed which data, when and with what operation is on record.
08
Continuity and operations
If the local model crashes, does the platform go down?
No. The local model runs in a separate process; a model crash does not stop the platform. Crash-loop protection is in place — a continuously restarting process cannot tie up the system.
Does a schema change require downtime?
No. Schema changes need no restart; the definition is updated and the runtime stays up.
Does a dropped connection create duplicate records?
No. The offline client queue is idempotent; within a 24-hour window, resending the same request does not create a second record.
361 AI Operating System — IT Review Pack · 361.com.tr/en/it-review.html