Security Overview
- Your agent runs in a dedicated, isolated sandbox — one per agent, not shared with anyone else
- Your agent's sandbox is secretless — credentials are never stored in the sandbox; they're injected per tool call and discarded after
- Query results are not independently stored — raw query payloads are discarded after processing, but tool invocation history (including summarized results) is serialized and persisted as part of the conversation thread
- Telemetry flows to your App Insights — you have full visibility into agent operations
Your agent is built with defense-in-depth security. This page covers how execution is isolated, where credentials live, and what happens with your data.
For how your agent gets permissions on Azure resources, see Agent Permissions. For identity details, see Agent Identity.
Execution isolation
Each agent gets its own isolated sandbox — a dedicated compute environment running in a separate micro VM. Your agent uses this sandbox to run tools (queries, code, bash commands), and it is not shared with other agents or customers.
- The agent communicates with its sandbox through structured API calls — no direct file system or process access
- Tool executions use thread-scoped sessions — Python and terminal tools reuse a stable sandbox session within a conversation thread (keyed by agent name + thread ID), so files and environment persist across tool calls in the same thread. Sessions are not shared across threads.
- Python code and shell commands run inside the sandbox with 700+ preinstalled packages. Users cannot install arbitrary packages, and network access is limited to known service domains
Secretless credentials
Your agent uses its sandbox to run tools, and that sandbox never stores credentials. When your agent needs to call an external service (query logs, read Azure Monitor, call an API):
- A separate identity service provides short-lived tokens scoped to each individual tool call
- Tokens are injected through a network proxy — tool code never handles credentials directly
- When the tool call completes, the token is discarded
Data residency
When your agent investigates an issue, it queries your data sources. A common question: does the agent store that queried data?
What is NOT independently stored
Raw query results — log entries, metrics, API responses — are not written to a separate data store. When the agent processes a tool call, it serializes the chat and tool messages (including result summaries) into the persistent conversation thread. The full raw payloads are discarded after processing, but serialized message content — which may include excerpts or summaries of query results — is retained as part of the thread history.
What IS stored
| Data | Retention | Purpose |
|---|---|---|
| Conversation threads | Until manually deleted | Chat history and investigation records |
| Session insights | Persistent | Synthesized learnings — symptoms, resolution steps, root causes |
| Memory files | Persistent across sessions | Team context, repo instructions, synthesized knowledge |
| Thread files | Tied to thread lifetime | User uploads, generated reports |
Session insights are synthesized summaries — not raw data copies. Full raw query payloads are not independently persisted, but serialized tool messages (which may include result excerpts) are stored as part of the conversation thread history.
All data at rest uses Azure-managed encryption. All external communication uses HTTPS.
Per-agent isolation
Each agent's data is isolated at every level:
| Layer | How it's isolated |
|---|---|
| Compute | Dedicated sandbox per agent — no shared execution between agents |
| Storage | Separate database and blob storage per agent — data is never co-mingled |
| Network | All outbound requests routed through the agent's own proxy |
| Credentials | Per-agent managed identity with RBAC roles scoped to your resource groups |
No data, compute, or credentials are shared between different agents or customers.
Logging and observability
Your agent sends operational telemetry to your Application Insights instance. This gives you full visibility into:
- Conversation traces with correlated request tracking
- Tool call details — what was called, how long it took, whether it succeeded
- Errors and exceptions
- Hook activations and incident events
On-behalf-of fallback
When your agent's managed identity lacks permissions for an operation, it falls back to acting on your behalf. You see an Approve action prompt with operation details, and the operation only proceeds after your approval. Your OBO token is stored on the approval record and used for the duration of the task — see Permissions for the full lifecycle.
This is controlled by run modes — Review mode requires approval for write operations, Autonomous mode uses the agent's managed identity directly.
Related concepts
| Concept | What it covers |
|---|---|
| Agent Identity → | What identities get created and how connectors use them |
| Agent Permissions → | RBAC roles, permission levels, and the approval flow |
| Run Modes → | ReadOnly, Review, and Autonomous modes |
| Code Interpreter → | Python and shell execution in the sandbox |