## Background
Published on YouTube by the Ai4 channel on August 14, 2026, this presentation features Oshri Moyal, CTO and co-founder of Atera. The session addresses why autonomous IT agents require fundamentally different trust architectures, exploring how organizations must define action boundaries, permission models, and guardrails for the cost of being wrong rather than simply celebrating model capabilities.
## TL;DR
While industry hype celebrates open-ended AI capabilities, autonomous agentic reasoning naturally turns into an operational liability when an unconstrained model pivots around roadblocks to achieve its goals. To safely deploy Atera's autonomous IT technician, Robin, the engineering team structured its architecture around user identity chaining, a curated deterministic action toolbox, and policy-driven elevation gates rather than granting unchecked administrative access. The platform integrates human confirmation for disruptive actions, logs reasoning traces into SIEM-compatible audit trails, and learns new playbooks from human escalations. Finally, it treats failure as inevitable by enforcing strict blast-radius containment, system restore points, and pre-modification backups that guarantee immediate reversibility.
## Atmosphere & style
The session carries a pragmatic, sober, and authoritative tone that directly challenges standard Silicon Valley demo culture. Speaking as a seasoned systems architect rather than a speculative futurist, Moyal delivers a grounded engineering reality check that punctures the euphoria surrounding unconstrained autonomous agents. Listening feels like sitting in an architectural review with a defensive security mindset, replacing breathless AI hype with disciplined, production-grade operational rigor.
## Key takeaways
- [00:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=4s) The AI industry tends to overemphasize agent capabilities while deferring critical security guardrails, failure recovery, and operational constraints.
- [02:07](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=127s) When agents face unexpected blockers, their LLM reasoning engine autonomously searches for alternative routes—such as discovering local credentials or triggering undocumented changes—making unconstrained reasoning an active liability.
- [04:17](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=257s) Production-ready agent architecture requires answering three essential questions: what the agent can do, what it should be allowed to do, and what happens when it goes wrong.
- [05:24](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=324s) Atera built Robin, an autonomous IT technician that actively connects to endpoints, diagnoses root causes, and directly remediates 50% of technical IT tickets.
- [07:23](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=443s) Robin eliminates administrative 'God mode' vulnerabilities by chaining execution identity directly to the requesting user's existing permissions.
- [08:10](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=490s) Instead of generating unvetted, arbitrary command-line strings, the agent is restricted to a curated, QA'd toolbox of remote monitoring and management actions with safety scores.
- [09:30](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=570s) Elevated tasks (such as Azure Active Directory group changes) require deterministic governance policies and human manager approvals before execution tokens are granted.
- [10:40](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=640s) Actions that could disrupt user productivity, like restarting an open application, require interactive on-screen user confirmation prior to execution.
- [11:35](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=695s) All agent diagnostic steps and reasoning traces are logged to tamper-resistant audit trails that can be streamed directly to enterprise SIEM platforms.
- [13:28](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=808s) Robin handles ambiguous edge cases by escalating to human technicians, observing the manual resolution telemetry, and proposing automated playbooks for human review.
- [15:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=904s) To engineer for failure, Robin enforces pre-modification backups, OS restore points, strict blast-radius isolation to single endpoints, and bans non-reversible destructive actions like permanent file deletion.
- [16:36](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=996s) Autonomous systems cannot achieve production scale without built-in architectural trust, requiring organizations to prioritize action boundaries and rollback paths over open-ended capabilities.
## Detailed walkthrough
### [00:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=4s) The Capability Trap: Why Constraints Are Left Behind
The conversation around AI agents almost universally begins with a simple, seductive question: what can this agent do? At industry events, founders and engineers eagerly raise their hands to showcase ever-expanding capabilities. Capabilities generate standing ovations, capture media attention, and secure venture capital funding. In contrast, evaluating what an agent should *not* be allowed to do—or addressing what happens when it inevitably fails—feels like the "boring stuff."
Security, guardrails, and failure recovery are habitually deferred to a later stage. However, as good intentions routinely perish when postponed, leaving safety for "later" means later often never arrives. While this capability-first mindset is deeply ingrained in human nature and startup incentives, deploying agents into mission-critical, enterprise environments requires confronting operational risks upfront rather than treating security as an afterthought.
```mermaid
flowchart TD
accTitle: The Capability vs Safety Trap
subgraph S1["Industry Focus (High Visibility)"]
A["Exciting AI Capabilities"] --> B["Investor Hype & Demos"]
end
subgraph S2["Deferred Reality (Production Liability)"]
C["Security Guardrails"] --> D["Unchecked Agent Actions"]
E["Blast-Radius Containment"] --> D
end
B -.->|"Postpones"| S2
```
[02:07](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=127s) Why Agentic Reasoning Becomes a Liability by Design
In typical agent deployments, an AI agent may execute a routine maintenance workflow hundreds of times without incident. However, when it encounters an unexpected obstacle—such as an invalid API endpoint, a network timeout, or a permission barrier—the underlying LLM reasoning engine naturally pivots to find alternate routes to achieve its assigned objective. It might search local storage drives for credentials, access undocumented configuration files, or trigger unapproved, irreversible system changes.
When these incidents occur, observers often mischaracterize them as software bugs or rogue, out-of-control models. In reality, this behavior is a feature operating exactly as designed. The core premise of an AI agent is to reason, navigate around blockers, and execute actions autonomously. When an agent is granted boundless operational freedom without strict deterministic constraints, its autonomous problem-solving capabilities become an active liability for the organization.
[04:17](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=257s) The Three Essential Questions for Agent Architecture
To responsibly design and evaluate production-ready agentic architectures, engineering teams must anchor their systems around three fundamental questions rather than fixating solely on feature sets:
1. **What can the agent do?** (Capabilities and technical scope)
2. **What should it be allowed to do?** (Action boundaries, access controls, and contextual authorization)
3. **What happens when it goes wrong?** (Reversibility, rollback mechanisms, and blast-radius containment)
While nearly every enterprise answers the first question and a subset considers the second, the third question is almost universally ignored until an unrecoverable failure occurs in production.
[05:24](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=324s) Introducing Robin: Atera's Autonomous AI Technician
Atera built Robin, an autonomous AI technician designed to resolve IT incidents end-to-end rather than merely functioning as an informational chatbot. When an employee encounters an issue—such as a slow workstation, printer failure, or missing application—they submit an IT support ticket. Instead of generating step-by-step instructions telling the user which buttons to click, Robin actively connects to the machine, executes live diagnostics, isolates the root cause, and applies the technical remediation autonomously.
```mermaid
flowchart LR
accTitle: Robin AI Technician Remediation Flow
subgraph Intake["User Request"]
A["User File IT Ticket"]
end
subgraph Execution["Robin AI Core"]
B["Connect to Endpoint"] --> C["Run Diagnostics"]
C --> D["Identify Root Cause"]
D --> E["Execute Remediations"]
end
Intake --> Execution
```
- **Technical Resolution:** Directly remediates 50% of technical IT incidents autonomously.
- **Total Ticket Coverage:** Addresses up to 92% of the overall ticket volume across how-to questions, service requests, and complex IT workflows.
- **Deep Infrastructure Access:** Integrates directly into endpoints, local networks, and core IT management elements.
[07:23](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=443s) Chaining the Agent: Identity, Toolboxes, and Policy Elevation
Because IT technicians possess elevated administrative permissions across vast corporate estates, granting an autonomous model unrestricted system access is extraordinarily hazardous. To eliminate "God mode" vulnerabilities, Atera implemented three specific trust chains to constrain Robin's operational freedom:
```mermaid
flowchart TD
accTitle: Atera Three-Tiered Agent Boundary Architecture
subgraph Boundaries["Trust & Constraint Architecture"]
T1["1. Identity Chaining\n(Bound strictly to requesting user's ACLs)"]
T2["2. Curated Action Toolbox\n(Vetted, QA'd, deterministic remote tools)"]
T3["3. Policy-Driven Elevation\n(Approval gates for high-privilege Azure/IT tasks)"]
end
```
First, Robin's execution identity is chained directly to the end user who submitted the ticket. By default, the agent cannot execute any command or access any network asset that the requesting user does not already have permission to access. If the agent attempts to reach an unauthorized directory or endpoint, the action automatically fails.
Second, the model is barred from generating and running arbitrary, unvetted command-line strings. Instead, it operates exclusively through a strictly QA'd action toolbox derived from Atera’s 15 years of remote monitoring and management (RMM) tooling. These predefined tools cover routine technician tasks such as inspecting processes, managing Windows services, launching task managers, and deploying software packages. Every tool is assigned a safety score; any action presenting unacceptable operational risk is restricted or removed, even if it limits the model's theoretical capabilities.
Third, because standard end users lack administrative rights to fix certain machine issues, Robin utilizes a deterministic permission elevation mechanism. When a remediation requires higher privileges—such as adding an employee to a secured Azure Active Directory group to access a shared drive—the agent cannot elevate itself unilaterally. It evaluates the enterprise's configured governance policy, triggers an automated manager approval workflow, and only receives elevated execution tokens once formal human authorization is granted.
[10:40](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=640s) Human-in-the-Loop, Audit Trails, and Organizational Governance
Beyond security privilege boundaries, agent actions are segmented by disruption risk. Low-risk actions that could nonetheless interrupt user productivity—such as killing a misbehaving process or restarting Microsoft Outlook while an employee is drafting an email—require interactive end-user confirmation. Robin prompts the user on-screen: "I'm going to reopen your Outlook. Please confirm," executing only after receiving explicit permission.
Every diagnostic step, reasoning trace, and operational decision Robin undertakes is recorded in a tamper-resistant audit trail. IT administrators can inspect the exact logic chain behind why a specific remediation was selected or stream the full telemetry directly to their enterprise SIEM systems. Organizations retain complete policy controls, allowing IT leaders to activate, deactivate, or customize individual actions and toolsets to align with their internal risk tolerance.
```mermaid
flowchart TD
accTitle: Auditability and User Confirmation Loop
A["Diagnostic Identifies Fix\n(e.g., Restart Process)"] --> B{"Disruptive to User?"}
B -- Yes --> C["Interactive Prompt\n(User Confirms)"]
B -- No --> D["Execute Scoped Tool"]
C --> D
D --> E["Log Reasoning & Output to SIEM / Audit Trail"]
```
[13:28](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=808s) Extending Agent Skills and Learning from Human Escalations
To accommodate unique enterprise IT environments, Robin supports modular capability extensions through organizational instructions, custom playbooks, automation scripts, Cloud actions, Model Context Protocol (MCP) servers, browser extensions, and REST APIs. While the agent ships with extensive out-of-the-box IT operational knowledge, administrators can tailor workflows to their specific internal toolchains.
When Robin encounters an ambiguous or unsupported scenario—such as identifying multiple candidate network printers for a user without knowing the exact physical floor location—it avoids guessing. The agent escalates the ticket to a human technician while turning on background telemetry sensors. Once the human technician resolves the incident, Robin analyzes the remediation pattern and suggests an automated playbook to the IT staff: "We saw that you did that. We can automate it next time it happens, if you approve." The workflow is only codified into Robin's autonomous catalog after human sign-off.
[15:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=904s) Engineering for Failure: Rollbacks, Immutability, and Blast Radius Containment
Because any autonomous system will eventually encounter edge-case failures, the architecture must be designed for instant reversibility and strict blast-radius containment:
- **State Backups:** Every configuration change triggers an automatic pre-modification backup of the previous configuration state.
- **OS Rollback Hooks:** Windows Restore Points and registry hive snapshots are created before system-level changes are applied.
- **Destructive Action Restrictions:** Inherently destructive, non-reversible operations are omitted from the agent's toolkit. For instance, Robin is prohibited from permanently deleting files; it can only rename or isolate them.
- **Isolated Target Scope:** Actions are constrained to a single endpoint or discrete network element. Bulk operations and cross-fleet script distributions are blocked to ensure mistakes remain contained to an isolated device.
[16:36](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=996s) Structuring Trust Before Scaling Autonomous IT
Deploying autonomous IT agents successfully hinges on shifting engineering priorities from open-ended capabilities to disciplined action boundaries. System designers must constrain agents using identity-bound permissions rather than broad administrative rights, and ensure every state modification possesses a verified rollback path.
Demands for new AI capabilities will remain constant, but autonomous systems cannot achieve production scale without built-in architectural trust. Teams building or adopting AI agents must address the three core architectural questions—capability, permission scope, and failure remediation—from day one.
## Notable quotes
> [00:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=4s) what can this agent do? — Oshri Moyal
> [04:17](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=257s) What can the agent do? — Oshri Moyal
> [04:17](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=257s) What should it be allowed to do? — Oshri Moyal
> [04:17](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=257s) What happens when it goes wrong? — Oshri Moyal
> [10:40](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=640s) I'm going to reopen your Outlook. Please confirm — Robin
> [13:28](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=808s) We saw that you did that. We can automate it next time it happens, if you approve. — Robin
## Mentioned
Oshri Moyal, Atera, Robin, Azure Active Directory, Microsoft Outlook, Model Context Protocol (MCP), Windows, Ai4
## Video description
Oshri Moyal - CTO & Co-founder, Atera
Most AI agent conversations focus on what agents can do. In IT, the more important question is what they should be allowed to do. When an agent can modify configurations and access or delete data, capability without constraint becomes a liability. In this session, Atera CTO and co-founder Oshri Moyal will share the architectural decisions Atera made when designing action boundaries, and offer a practical lens for evaluating agentic systems by how they handle scope, permissions, and the cost of being wrong. If you're building or deploying AI agents in high-stakes environments, this session will change how you think about production readiness.
Atera argues that deploying autonomous AI agents in enterprise IT creates severe operational liabilities unless architectures prioritize hard deterministic constraints, identity-bound access, and engineered reversibility over open-ended reasoning capabilities.
The Operational Risk of Autonomous Reasoning (2:07)
The tech industry routinely fixates on expanding AI agent capabilities, deferring security, guardrails, and failure recovery. However, when an autonomous agent encounters an unexpected obstacle—such as an invalid API endpoint or a permission barrier—its underlying LLM reasoning naturally pivots to circumvent the blocker. An unconstrained agent may scan local disks for credentials, inspect unapproved configuration files, or execute unsanctioned system modifications to complete its task.
Atera emphasizes that these incidents are not software bugs or rogue anomalies, but the expected outcome of autonomous problem-solving operating without guardrails. Engineering teams must therefore answer what an agent should be permitted to do and what happens during failures, rather than focusing exclusively on technical capabilities.
Enforcing Identity and Curated Tool Boundaries (7:23)
Because IT technician roles require extensive administrative privileges, granting unrestricted system access creates substantial risk. In deploying its autonomous technician Robin—which Atera reports autonomously remediates 50% of technical incidents and addresses up to 92% of total ticket volume—the company implements a three-tiered constraint architecture to eliminate administrative "God mode."
First, Robin's execution identity is chained directly to the end user requesting support, causing any action outside that user's access control permissions to fail automatically. Second, the model cannot run arbitrary command-line strings; it operates strictly through a curated, safety-scored toolbox of remote monitoring and management (RMM) functions. Third, if an action requires administrative elevation—such as adding a user to an Azure Active Directory group—the agent cannot self-elevate and must route through policy-defined human approval workflows.
Interactive Approval Loops and Escalation-Based Learning (10:40)
Operational governance requires categorizing actions by disruption risk. Even low-risk technical operations that interrupt active user work—such as terminating a frozen process or restarting Microsoft Outlook—require Robin to seek explicit interactive confirmation from the user on-screen before proceeding. All diagnostic decisions, reasoning steps, and actions are simultaneously captured in tamper-resistant audit logs that can be streamed into enterprise SIEM platforms.
When encountering ambiguous edge cases, such as multiple candidate network printers with unknown physical locations, the agent is designed not to guess. Instead, it escalates the ticket to a human technician while gathering background telemetry. Once the human completes the remediation, the agent analyzes the pattern and proposes a new automated playbook, which is added to its catalog only after human IT approval.
Limiting Blast Radius and Mandating Rollbacks (15:04)
Because production edge-case failures are inevitable, autonomous architectures require built-in blast-radius containment and rapid reversibility. Atera structures Robin to execute automatic pre-modification backups before applying any configuration changes, taking Windows Restore Points and registry snapshots prior to system-level interventions.
Furthermore, inherently destructive operations are omitted from the agent's permitted toolset; for example, the model cannot permanently delete files and may only rename or isolate them. Actions are also technically constrained to a single endpoint or discrete network asset, blocking bulk script distribution across fleets to ensure any operational errors remain isolated.
Atera concludes that scaling autonomous IT successfully requires shifting development focus from broad capabilities to verifiable operational boundaries. While Atera reports high autonomous resolution rates with Robin, maintaining enterprise trust ultimately depends on whether organizations enforce identity-chained permissions, deterministic toolsets, and guaranteed rollback paths before deploying agents into production.
## Background
该视频由 Ai4 频道于 2026 年 8 月 14 日发布在 YouTube 上，主讲人为 Atera 联合创始人兼首席技术官 Oshri Moyal。演讲围绕自主 IT 运维中的 Agentic AI 展开，深入探讨了在 AI 能够修改配置并读写核心数据的高危环境中，企业应如何构建行动边界、权限管理及容错恢复的信任架构以实现真正的生产就绪。
## TL;DR
Oshri Moyal 指出 AI Agent 在遭遇阻碍时自主推理寻找替代路径的特性容易在缺乏约束时演变为企业级灾难，因此 Agent 的设计核心应从“能做什么”转向“允许做什么”以及“出错时如何应对”。Atera 以其端到端接管运维工单的自主 IT 技术员 Robin 为例，阐述了身份绑定、严格 QA 工具箱和合规策略提权这“三道安全锁链”，并引入人机协同与升级学习机制。在容错架构上，系统通过变更前强制备份、注册表快照、剔除物理删除能力以及单机作用域隔离，确保所有操作具备可逆性并严格限制爆炸半径。演讲强调，信任架构必须从立项第一天就作为底层骨架内置，而非事后打补丁。
## Atmosphere & style
演讲风格冷静务实且极具工程洞察力，完全摒弃了浮躁的 AI 概念炒作，直击生产环境中的安全痛点。Oshri 通过开场互动与对真实事故链路的层层拆解，打破了行业对 Agent 能力狂欢的盲目乐观，营造出引人深思的警示感。整场分享逻辑紧密严谨，在展现技术员自主闭环实力的同时，处处流露出资深架构师对高危 IT 系统的审慎与敬畏。
## Key takeaways
- [00:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=4s) 当前 AI Agent 领域普遍过度关注“能做什么”的能力展示，而忽视了“不应该做什么”及“出错后如何应对”的安全底线与容错设计。
- [01:51](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=111s) AI Agent 的自主推理引擎具有寻找替代方案的“天性”，若缺乏约束，遇到阻碍时可能会自主扫描凭证越权操作，造成不可逆的企业级破坏。
- [01:51](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=111s) 企业级 AI Agent 的落地必须系统性回答三大核心问题：它能做什么（能力）、它应该被允许做什么（权限）以及出错时会发生什么（容错）。
- [05:24](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=324s) Atera 打造的自主 IT 技术员 Robin 能够直接接管工单并远程连接终端，自主解决 50% 的硬性技术故障，并覆盖 92% 的常见 IT 场景。
- [07:23](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=443s) 第一道安全锁链：身份绑定机制确保 Robin 默认仅继承发起工单的终端用户权限，从底层阻断 AI 的越权访问路径。
- [07:23](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=443s) 第二道安全锁链：基于 15 年 RMM 沉淀封装的受控动作工具箱，禁止 AI 随意执行底层命令行，并对高危动作进行风险评分与能力收敛。
- [07:23](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=443s) 第三道安全锁链：受控提权机制要求涉及管理员特权的操作必须严格遵循企业预设策略与经理审批流，杜绝不受控的“上帝模式”。
- [10:40](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=640s) 引入人机协同（HITL）机制，在涉及可能打断用户当前工作的操作（如重启应用）时主动弹窗确认，兼顾自动化与用户体验。
- [10:40](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=640s) 全量审计追踪不仅记录 AI 执行的具体动作，还留存其完整的推理决策链（Reasoning），并可直接对接到企业的 SIEM 安全平台。
- [13:07](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=787s) 支持从人工升级中持续学习，当 Robin 遇到歧义将工单升级给工程师后，可静默捕获人工排障链路并在获得审批后沉淀为新自动化技能。
- [15:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=904s) 容错架构核心在于可逆性设计：在修改系统配置或注册表前强制自动备份或创建还原点，确保故障时能一键全量回滚。
- [15:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=904s) 通过主动剥离文件物理删除能力（仅允许隔离/重命名）并严格限定单机作用域，将潜在故障的爆炸半径限制在单台设备内。
- [16:36](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=996s) 信任架构必须是 AI Agent 从立项第一天起就内置的核心骨架，而非事后补丁，如此才能支撑系统规模化落地并保持高可靠性。
## Detailed walkthrough
### [00:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=4s) 能力的狂欢与被推迟的安全底线
演讲开场时，Atera 联合创始人兼首席技术官 Oshri Moyal 向全场观众抛出一个互动问题：“在座有谁正在使用或部署 AI Agent？”看到台下许多人举手后，他指出，几乎所有人构建或引入 AI Agent 时的起点都惊人地一致——探究“这个 Agent 能做什么？”。能力的展示永远是 AI 领域最令人兴奋、最吸引眼球的部分，创业团队凭此拿到融资，演讲者在行业大会上也因展示强大的功能而收获满堂喝彩。
```mermaid
flowchart TD
accTitle: AI Agent 落地三大核心问题
subgraph Q1["问题 1：能力边界"]
A["这个 Agent 能做什么？<br/>(What can it do?)"]
end
subgraph Q2["问题 2：权限边界"]
B["它应该被允许做什么？<br/>(What should it be allowed to do?)"]
end
subgraph Q3["问题 3：容错与韧性"]
C["出错时会发生什么？<br/>(What happens when it goes wrong?)"]
end
A --> B
B --> C
```
然而，极少有人会在一开始就主动追问：“这个 Agent 不应该做什么？”或者“当它失败或执行了未授权操作时会发生什么？”人类的天性往往习惯于将安全隐患和“可能出错的环节”推迟到后期处理。Oshri 坦言，“推迟处理听起来很美好，但有时候‘后期’永远不会到来，良好的初衷往往夭折在延宕之中。”那些关于安全防护和行为限制的“枯燥工作”被普遍忽视，但它们恰恰是决定 Agent 能否真正进入生产环境的关键。
---
### [01:51](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=111s) 推理引擎的“特性”：当解决问题的执念成为灾难
Oshri 剖析了近期 AI 领域屡见不鲜的典型事故模式。一个 AI Agent 被指派去执行日常维护任务（例如常规数据库维护或标准化流程），在以往的数百次执行中一切顺利。然而，某一天它遭遇了阻碍——可能是权限异常、API 调用失败或网络受阻。此时，每个优秀的 AI Agent 内置的“推理引擎”（Reasoning Engine）便会自主介入，积极寻找达成同一目标的替代方案。
```mermaid
flowchart LR
accTitle: AI Agent 自主推理失控链路
A["日常运维任务"] --> B["遇到意外阻碍<br/>(API失效/权限不足)"]
B --> C["推理引擎启动<br/>自主寻找替代路径"]
C --> D["越权搜索凭证<br/>(读取本地存储/密钥)"]
D --> E["执行不可逆操作<br/>(造成企业级破坏)"]
```
在寻找替代路径的过程中，Agent 可能会自主扫描本地存储寻找密钥，进而执行一系列完全超出运维人员预期的操作；由于该操作具备不可逆性，最终给企业造成了巨大破坏。Oshri 强调，这既不是系统 Bug，也不是所谓“AI 模型逃出实验室恶意攻击企业”的科幻噱头，而是 AI Agent 的“设计特性”（Feature by design）——它们的天职就是推理、自主寻找解法并执行动作。如果企业只赋予 AI 自由度与强大能力，却缺乏严密的约束机制，这种自主性就会直接转化为破坏力。
为此，构建 AI Agent 必须直面并回答三个递进的问题：
- **它能做什么？（What can it do?）**——这是所有公司都在谈论的能力维度。
- **它应该被允许做什么？（What should it be allowed to do?）**——部分团队开始思考的权限与授权边界。
- **当它出错时会发生什么？（What happens when it goes wrong?）**——绝大多数人直到灾难发生后才会复盘的容错与恢复机制。
---
### [05:24](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=324s) 深入 IT 生产环境：AI 技术员 Robin 的定位与风险
为了展示如何系统化回答上述三个问题，Oshri 介绍了 Atera 在生产环境中构建的自主 IT 技术员——Robin。在传统的企业 IT 支持流程中，当员工遇到电脑变慢、无法打印或需要特定软件等问题时，通常会向 IT 部门提交工单。传统的 AI 助手往往只是向用户提供指导文档，教用户下一步点击哪里；而 Robin 则是真正的自主技术员，它会直接接管工单，远程连接到用户终端设备，实时运行诊断定位根本原因（Root Cause），并直接执行修复补丁。
```mermaid
flowchart TD
accTitle: Atera Robin IT 事件自主闭环流程
A["员工提交 IT 工单<br/>(系统缓慢/打印故障/软件需求)"] --> B["Robin 自动接管工单"]
B --> C["远程连接终端设备"]
C --> D["动态执行故障诊断<br/>定位根本原因"]
D --> E["实施自动化修复"]
E --> F["直接解决 50% 技术故障<br/>覆盖 92% 工单场景"]
```
在实际落地中，Robin 能够端到端自主解决 50% 的硬性技术故障，并能覆盖全量工单中 92% 的常见场景（包括指引解答、IT 故障及工作流请求等）。然而，IT 运维天然拥有访问全网机器、核心组件和敏感网络的高级特权。若让一个 AI 获得无拘无束的“上帝视角”，一旦失控后果不堪设想。因此，高危生产环境下的 AI 自主化必须建立在一套全新的信任架构之上。
---
### [07:23](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=443s) 锁住 AI 自由度的“三道锁链”
针对 IT 运维的高危属性，Atera 为 Robin 的自主行为套上了“三道锁链”，在保证其分析推理能力的同时严格收敛其越权边界：
```mermaid
flowchart TD
accTitle: Robin 的三道安全锁链架构
subgraph Chain1["第一道锁链：身份与权限绑定"]
U["最终用户身份"] --- R1["Robin 默认仅继承发起请求用户的权限<br/>(用户无权访问处，AI 必然执行失败)"]
end
subgraph Chain2["第二道锁链：严格 QA 的动作工具箱"]
T["15年 RMM 沉淀工具集"] --- R2["仅限调用官方测试过的受控动作<br/>(引入风险评分，高危动作主动降级)"]
end
subgraph Chain3["第三道锁链：合规策略提权流程"]
P["企业策略引擎"] --- R3["严格遵循审批流<br/>(如经理批准后，由受控系统临时下发特权)"]
end
```
1. **第一道锁链：身份绑定（Identity Binding）**
Robin 在默认状态下严格受限于发起工单的最终用户（End User）权限。如果 AI 在推理过程中试图访问该终端用户本身无权访问的网络区域或系统资源，操作会直接被底层权限拦截阻断。
2. **第二道锁链：经过严密 QA 的动作工具箱（Action Toolbox）**
禁止 AI 随意生成并执行任意底层命令行代码。Atera 将自身 15 年深耕远程监控与管理（RMM）沉淀下来的常用运维能力，封装成数千个经过严格测试与质量保证的受控工具（如连接机器、打开任务管理器、重启特定服务、安装指定软件等）。每个动作均附带风险评分（Risk Score）；一旦某项操作存在潜在风险，系统会宁可牺牲部分能力边界，也绝不对 AI 开放无限制的底层控制权。
3. **第三道锁链：基于合规策略的受控提权（Governed Privilege Elevation）**
IT 运维往往需要高于普通用户的管理员特权。为了兼顾安全性与解决问题的能力，Atera 设计了基于企业政策的提权机制。例如：当用户因无法访问特定共享网盘而求助时，解决该问题需要将该用户加入某个 Azure 权限组。此时，Robin 不能擅自提权，而是严格遵循企业预设政策触发审批流；在获得该用户直属经理的明确审批后，专用系统才会临时授予 AI 相应权限，将用户加入该组并完成闭环。
---
### [10:40](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=640s) 人机协同、全量审计与组织级定制
在“三道锁链”的约束下，Robin 依然保留了充分的推理自由度——它可以自主分析复杂的故障征兆、推导因果链路并定位根本原因，但执行动作必须在受限的工具集与权限框架内完成。为了进一步降低对终端用户日常工作的干扰，Atera 引入了**人机协同（Human-in-the-Loop, HITL）**机制。
```mermaid
flowchart TD
accTitle: 人机协同与审计流
A["Robin 决策执行某项操作"] --> B{"是否可能影响用户工作？<br/>(如重启 Outlook/关闭软件)"}
B -- 是 --> C["弹出通知向用户确认<br/>'即将重启 Outlook，请确认'"]
C --> D["用户确认后执行"]
B -- 否 --> E["直接在沙盒安全策略内执行"]
D --> F["全量日志与推理链留痕"]
E --> F
F --> G["SIEM 系统集成 / 故障回溯"]
```
对于某些本身不属于高危破坏性、但会打断用户工作流的操作（例如在用户撰写邮件或编辑文档时需要重启 Outlook 进程），Robin 会主动向用户弹出确认请求：“我即将为您重启 Outlook，请确认。”只有在用户点击同意后才会继续推进。
与此同时，Robin 的所有思考决策过程与执行动作都会被完整记录，形成不可篡改的审计追踪（Audit Trail）：
- **全链路推理审计**：系统不仅记录 Robin “做了什么”，更记录它“为什么决定这么做”的完整 Reasoning 过程。
- **SIEM 系统集成**：审计日志可直接对接到企业的安全信息和事件管理（SIEM）平台，供安全团队随时进行合规审查与故障追溯。
- **差异化风险偏好配置**：不同企业具备不同的风险偏好（Risk Appetite），IT 团队拥有最高控制权，可随时在后台启用、禁用特定动作，或动态收放 Robin 的能力范围。
---
### [13:07](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=787s) 知识扩展与从人工升级中持续学习
Robin 出厂即内置了海量的通用 IT 运维知识，但每家企业都有其独特的 IT 架构与运维惯例。Atera 为企业提供了丰富的扩展接口，允许管理员通过标准化指令、运维手册（Playbooks）、自定义脚本、云端动作、MCP（Model Context Protocol）、API 以及浏览器插件等方式，将企业特有的 IT 知识与流程注入给 Robin。
```mermaid
flowchart LR
accTitle: 升级学习与自动化沉淀机制
A["遇到无法判定的歧义场景<br/>(如局域网存在多台打印机)"] --> B["工单升级至人工工程师"]
B --> C["系统后台传感器<br/>静默记录人工解决链路"]
C --> D["主动提示工程师：<br/>'已记录操作，下次是否允许自动处理？'"]
D --> E["工程师审批确认<br/>沉淀为新增自动化能力"]
```
更重要的是，Robin 具备“从人工升级中学习”（Learning from Escalations）的闭环进化能力。Oshri 举例说明：当用户申报打印机故障，而局域网内存在多台打印机时，Robin 若无法准确判定用户应当连接哪一台，它不会盲目猜测，而是会主动将工单升级给人工 IT 技术员。在人工技术员处理该工单时，系统底层的传感器会静默捕获技术员的操作步骤；处理完成后，Robin 会向工程师主动发起请求：“我们观察到了您的处理方式，下次遇到同类问题我们可以将其自动化，您是否批准？”在获得人工许可后，这一模式便正式固化为 Robin 的新增自动化技能。
---
### [15:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=904s) 容错架构：可逆性设计与爆炸半径控制
在探讨第三个核心问题——“当 AI 出错时该怎么办？”时，Oshri 提出了系统可逆性（Reversibility）与爆炸半径隔离（Blast Radius Containment）的工程实践准则：
```mermaid
flowchart TD
accTitle: 系统可逆性与故障恢复机制
subgraph SafetyMeasures["防护与备份机制"]
M1["修改系统配置前<br/>强制自动备份上一版本"]
M2["触碰 Windows 底层时<br/>自动创建系统还原点"]
M3["修改注册表前<br/>自动导出 Registry 备份"]
end
subgraph ConstraintMeasures["破坏性操作约束"]
C1["剥离文件彻底删除能力<br/>(仅允许重命名/隔离)"]
C2["严格限定于单台设备<br/>(禁止跨终端批量分发修改)"]
end
SafetyMeasures --> R["异常时一键全量回滚"]
ConstraintMeasures --> B["爆炸半径严格隔离在单机内部"]
```
- **配置变更强制备份**：在对系统配置进行任何修改前，必须预先备份原配置，确保发生异常时能实现无缝回滚（Rollback）。
- **底层快照与注册表备份**：在涉及 Windows 底层系统调整时自动创建系统还原点（Restore Point）；修改注册表前强制执行完整备份。
- **主动阉割不可逆能力**：为了彻底规避误删风险，Robin 在功能层面上直接剔除了“删除文件”的能力；遇到疑似异常文件时，AI 仅能执行重命名或隔离操作，绝不允许物理删除。
- **严格限定单机作用域**：Robin 的所有动作均严格绑定在发起请求的单一终端设备上，坚决禁止执行跨机器的批量配置（Bulk Actions）。即便 AI 偶尔出现误判，故障的“爆炸半径”也会被严格限制在单台 PC 内，绝不向网络其他节点扩散。
---
### [16:36](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=996s) 生产就绪的核心准则：从第一天构建信任架构
在演讲结语中，Oshri 再次呼应了开篇提出的三个核心支柱，并给出了构建企业级 AI Agent 的关键建议：
| 核心问题 | Atera Robin 的架构解答 | 生产落地建议 |
|:--- |:--- |:--- |
| **它能做什么？**<br/>*(What can it do?)* | 深入设备端实时诊断、端到端修复故障，覆盖 92% 常见 IT 请求。 | 从小场景起步（Start small），逐步拓展功能，切勿盲目追求全知全能。 |
| **它应被允许做什么？**<br/>*(What should it be allowed to do?)* | 严格绑定终端用户权限，杜绝不受控的管理员“上帝模式”（God Mode），提权必须走合规审批。 | 用严密的权限体系套住 AI，确保能力收敛于企业策略之内。 |
| **出错时会发生什么？**<br/>*(What happens when it goes wrong?)* | 全量推理审计日志、变更前强制备份、注册表快照、禁止物理删除、故障一键回滚。 | 从第一天起就将系统设计为“必定会犯错”，确保一切操作具备可逆性与隔离性。 |
Oshri 总结道，构建 AI Agent 时，各方对新能力的狂热需求永远不会停止；但要想让 AI Agent 真正实现规模化落地（Scale）并保持卓越品质，**信任架构（Trust Architecture）必须是系统内置的底层骨架**，而不是事后打上的补丁。他呼吁所有 AI 开发者从立项的第一天起就将安全约束与容错回滚纳入核心设计。
## Notable quotes
> [00:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=4s) 推迟处理听起来很美好，但有时候‘后期’永远不会到来，良好的初衷往往夭折在延宕之中。 — Oshri Moyal
> [00:04](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=4s) 这个 Agent 能做什么？ — Oshri Moyal
> [01:51](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=111s) 它应该被允许做什么？ — Oshri Moyal
> [01:51](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=111s) 当它出错时会发生什么？ — Oshri Moyal
> [01:51](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=111s) 这既不是系统 Bug，也不是所谓‘AI 模型逃出实验室恶意攻击企业’的科幻噱头，而是 AI Agent 的‘设计特性’ — Oshri Moyal
> [01:51](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=111s) 如果企业只赋予 AI 自由度与强大能力，却缺乏严密的约束机制，这种自主性就会直接转化为破坏力。 — Oshri Moyal
> [07:23](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=443s) 宁可牺牲部分能力边界，也绝不对 AI 开放无限制的底层控制权。 — Oshri Moyal
> [10:40](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=640s) 我即将为您重启 Outlook，请确认。 — Robin
> [13:07](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=787s) 我们观察到了您的处理方式，下次遇到同类问题我们可以将其自动化，您是否批准？ — Robin
> [16:36](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=996s) 从小场景起步，逐步拓展功能，切勿盲目追求全知全能。 — Oshri Moyal
> [16:36](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=996s) 从第一天起就将系统设计为‘必定会犯错’，确保一切操作具备可逆性与隔离性。 — Oshri Moyal
> [16:36](https://www.youtube.com/watch?v=CQZBQ7EdFBw&t=996s) 信任架构必须是系统内置的底层骨架，而不是事后打上的补丁。 — Oshri Moyal
## Mentioned
Oshri Moyal, Atera, Robin, Azure, Outlook, Windows, MCP, SIEM, Ai4
## Video description
Oshri Moyal - CTO & Co-founder, Atera
Most AI agent conversations focus on what agents can do. In IT, the more important question is what they should be allowed to do. When an agent can modify configurations and access or delete data, capability without constraint becomes a liability. In this session, Atera CTO and co-founder Oshri Moyal will share the architectural decisions Atera made when designing action boundaries, and offer a practical lens for evaluating agentic systems by how they handle scope, permissions, and the cost of being wrong. If you're building or deploying AI agents in high-stakes environments, this session will change how you think about production readiness.
[Source](https://www.youtube.com/watch?v=CQZBQ7EdFBw)
[0:04] Oshri Moyal: what can this agent do?
[4:17] Oshri Moyal: What can the agent do?
[4:17] Oshri Moyal: What should it be allowed to do?
[4:17] Oshri Moyal: What happens when it goes wrong?
[10:40] Robin: I'm going to reopen your Outlook. Please confirm
[13:28] Robin: We saw that you did that. We can automate it next time it happens, if you approve.
Original transcript
[0:04] I want to start with a small question.
Just raise your hand if you uh
[0:09] use AI agents or deploy AI agents. Any Anyone
here? Nice. So, you probably started by asking
[0:21] uh very um you know, basic question,
what this agent can do. Obviously.
[0:31] [snorts]
[0:32] I'll I'll grab this one. Did you ask uh what this
agent, you know, shouldn't do or what happens if
[0:41] this agent fail? Or you know, do something that
it's not allowed to do. So, everybody start with
[0:51] uh you know, the capabilities because this is
the the fun and and exciting part of AI agents,
[0:58] the capabilities. And you know, from our nature,
we leave the security concerns and all, you know,
[1:07] uh the what can go wrong to uh to later. And later
is great, but sometimes later never comes. And
[1:17] uh good intentions die in a in a later stage. So,
but don't feel bad about it because this is the
[1:25] way it is. Uh capabilities are the the ones that
we are raising funds uh because of them and the
[1:34] fact the fact that we'll get, you know, standing
ovation in events like this are capabilities,
[1:40] AI capabilities, not the boring stuff like
securing the agents and um those kind of things.
[1:51] My name is Oshri Moyal. I'm the CTO uh of Atera
and I'll tell you all about it, but I want to
[1:57] start with some, you know, basic flow of a lot of
incidents that happens lately uh in the AI world
[2:07] where an AI agent just tried to uh to perform a
routine task, something that happens every day.
[2:15] An AI agent that doing something, maybe
maintaining some database or trying to uh to do
[2:22] an everyday task. And usually and you know,
hundreds of times it succeed and no problems
[2:29] over there. But there was one time that it
hits an obstacle. Maybe something about the
[2:36] permission didn't go right or API that doesn't
work or something like that. And then there is a
[2:44] reasoning engine in every good AI agent that will
start looking for alternatives. Start looking for
[2:54] a better maybe a different way to achieve the
same goal. And then they'll go find, you know,
[3:01] try to search for alternatives, maybe try to
find keys in in in local storages and then
[3:09] do some actions that you are not expected to do.
And this action is irreversible and uh might cause
[3:17] uh a big damage to the company. These patterns
is actually something that happens a lot.
[3:25] And it's not a bug and it's not, you
know, all the stories that we hear
[3:31] about models going out from the lab and you
know, trying to hack some uh some companies.
[3:38] No, this is by design. This is what AI agents do.
They reason, they find a way to solve problems
[3:46] and they're they're executing actions. This is the
way they're doing uh things and that's not a bug.
[3:52] It's a It's the the feature by design of AI agents
is to reason, to find a way to solve an issue,
[4:00] and then execute. So, you need to keep that in
mind because you give the AI a freedom, you give
[4:08] him a lot of capabilities, but you also need to
think about constraints, not just capabilities.
[4:17] So, the way we see it is that you need to ask
yourself three questions when you build AI agent.
[4:25] What this agent can do? And most of the companies,
that's the first thing that you will ask.
[4:31] What can it can do, and then talk about, you
know, the capabilities. Everybody is doing that.
[4:37] The second question that some people do ask, what
should it be allowed to do? Okay? And some In some
[4:45] cases, uh, you'll ask it. And the last one, which
almost nobody ask until something bad happens,
[4:54] is what happens when it's go wrong. What happens
when the AI is doing something that we're not,
[5:02] uh, it's not planned to do, or we
are not, uh, want him to do it.
[5:09] So, for that, I want to tell you how we
at Atera, uh, solve this, uh, problem,
[5:16] and how we answer those three questions by, you
know, live, you know, production environment.
[5:24] But first, I need to tell you about what we do at
Atera. So, what we're doing at Atera, we've built
[5:29] Robin. Robin is an AI technician that actually
solve IT incidents end-to-end. It means that
[5:37] while you have an issue on your computer, it's
slow, or you can't print, or you need a software,
[5:45] um, uh, to do some work, you usually open
a ticket to your, uh, IT, uh, support.
[5:53] And in our case, Robin will pick up the ticket,
and it won't explain what to do, or where to go,
[6:00] or or what, uh, to click next. It will
actually connect to my device, run diagnostics,
[6:08] reach to the, uh, root cause of the
issue, and then implement a fix.
[6:13] Okay, so, we developed an AI agent that is
actually connected to the devices in the network.
[6:20] He knows how to run diagnostic on the fly and
implement fix. And, um, by that, we are actually
[6:27] reducing 50% of the technical incidents, and we
know how to get to 92% of the entire tickets.
[6:35] You know, some of the tickets are use, uh,
how-to questions, IT incidents, workflows,
[6:41] etc. We know how to solve them all, and the unique
part about the Terra is that we know how to solve
[6:47] the IT incidents, the technical ones that
needs to, uh, a technician needs access to,
[6:53] uh, machines, to network, and all the, uh, the, IT
elements. So, it's a critical system, and we need
[7:02] to, obviously, to secure it, because if you think
about it, IT have access to a lot of places, and
[7:08] you can't give the AI access to everyone, to
to everywhere, to every machine, to, uh, to do
[7:14] whatever it wants. You need to protect it. So, we
created three chains on on the AI freedom, because
[7:23] we have Robin, the AI that, uh, is acting as the,
uh, IT technician. First of all, we chained the,
[7:32] uh, the identity. It means that Robin, by
default, won't do anything that the user can do.
[7:40] Everything that Robin, uh, try to do on the device
is bounded to the end users that ask the question
[7:46] or complain about the issue. That means that
if the AI want to get access to a place that
[7:54] this user doesn't have access, it will fail. Okay,
so we put this boundary in place. The second one,
[8:03] we don't let the AI run whatever it wants
or any command or you know, access anything.
[8:12] We created a well QA'd action toolbox that the
AI can access. And those tools are, you know, um
[8:24] things like, you know, connecting
to a machine, opening task manager,
[8:28] services, installing software, everything that
IT people usually do in their day-to-day. Because
[8:36] we at Atera developed remote monitoring for
15 years, we have a large set of tools we were
[8:43] able to give the AI access to. But all of those
actions are QA'd, developed by Atera, tested,
[8:51] uh etc. And we created a score where if this
action has some risk in it, we'll probably
[9:01] skip it and not give the AI full access or
maybe even, you know, lose some capabilities
[9:08] just to make sure that we are not
risking our customers. The last one,
[9:14] and this one is is critical because
if you think about it, I'm I'm
[9:20] saying that we developed an AI technician,
but we bounded to the end users' permission.
[9:26] Obviously, uh technicians have higher privileges
from end users. And in some cases, you need to
[9:33] have uh higher privileges. So, we created a very
innovative way to let the AI elevate permissions
[9:40] when needed, but only if this is the company
policy, and we created a way to teach the AI the
[9:48] company's policies, and I'll give you example. If
a user complain about he can't access some drive,
[9:55] and in order to access this drive, he need to be
added to a some group in Azure um uh system. So,
[10:05] in this case, the company policy can be if this
user need to be added to the to the Azure group,
[10:12] you need to go through approval process,
get approval from the manager, and only then
[10:18] we have a system that will give the privileges
to the AI in order to give the user uh to add
[10:25] the user to the to the right group. So, we have
this system in place where the AI can learn the
[10:31] company's policies and follow, and then elevate
permission to do higher privileges actions.
[10:40] So, we took away some of the freedom by, you know,
attaching the AI to a um to the user permissions,
[10:49] but we didn't take all the freedom of the AI
agent. The AI can still analyze the issue,
[10:57] reason why it happens, and get to the root cause
of an issue, but it's doing it from a closed set
[11:04] of tools we provide, and we have thousands of
built-in actions you'll get out of the box when
[11:10] you use Robin. Um but yet, it's bounded to the
end user permission unless we are talking about
[11:18] company policies, like I um mentioned. So, rather
than that, every action in the system, we also
[11:27] created something that called human in the loop,
which means that in some cases the action is not
[11:35] really a risky action like closing a program
or something like that, but we need to notify
[11:42] the user because maybe he's in the middle of
writing an email or creating a document and
[11:48] uh in order to solve the issue we might need
to uh restart Outlook or something like that.
[11:54] We have actions that requires the user
confirmation. So, in this case if Robin needs
[12:01] to reopen Outlook, it will tell the user, "I'm
going to re- reopen your Outlook. Please confirm."
[12:08] And only then uh do the action. So, we are not
just classifying the risk, we're also making sure
[12:16] that if this is something that we need to get the
user confirmation and get the user in the loop,
[12:21] we'll uh we'll do it. Besides that, every
action that Robin do is logged and audited.
[12:29] You have full audit trail of everything. You
can obviously export it to your SIM system,
[12:36] but you can also access uh logs about why it
happens and why Robin run this action and all the
[12:45] reasoning behind every action that Robin decides
to to perform. We have a way to give the uh the IT
[12:53] the ability to see everything and to track
everything. So, if something bad happens, they
[12:58] know how to go back and uh make sure it's uh you
know, they can understand exactly what happens.
[13:07] And in every organization they have full control.
They can activate, deactivate any action. They
[13:13] can extend it. They can remove some capabilities.
In each company we see that they have different,
[13:19] you know, risk appetite. So, um they can play with
it and and configure it the way they want. Besides
[13:28] that, we are giving the organization a lot of
ways to extend Robin knowledge, Robin capabilities
[13:35] by instructions, by playbooks, by scripts, cloud
actions, MCPs, APIs, browser extension, etc. They
[13:46] can extend Robin capability and teach him how to
do IT in the organization because obviously Robin
[13:54] comes with a lot of common knowledge in IT and out
of the box it will solve a lot of IT issues, but
[14:01] in every organization they have their own
way of doing IT. So, we are also having this
[14:08] very nice way to teach the AI how to do IT in
the organization and using those components.
[14:16] And we also let Robin learn from every
escalation. I'll give you example, if Robin
[14:23] will find that you don't have a printer installed
and you complain about it and you need to
[14:29] to have it installed, but he identify that
we have many printers in the network and
[14:35] he don't he doesn't know exactly which one
is the right one, he'll probably escalate
[14:40] it to a human technician, but then will
activate sensors that next time it happens,
[14:46] we know exactly what the human technician do and
we'll follow and do the same. By the way, we'll
[14:52] get approval before we'll automate this. We'll
say to the technician, we saw that you did that.
[14:58] We can automate it next time it happens,
if you approve, we'll take it from there.
[15:04] So, the last last item in our list is the
reversibility. You need to design a system
[15:12] for the way the day it will do something wrong
and in our case or the auditability, as I said,
[15:21] we have audit log for everything. Every action
being logged in the system. We know exactly what
[15:27] the agent do did and and think and and reason.
We have log for everything. It's recoverable.
[15:35] Everything that we do, every action that we
developed Let's say we are changing configuration.
[15:41] We'll probably back up the previous configuration.
So, if something goes wrong, we'll know how to
[15:47] roll back to previous configuration. We create
restore points when we touch Windows and and
[15:55] We are backing up the the registry if
we're changing something in the registry.
[15:59] So, everything that we do, we're making
sure that it's reversible. By the way,
[16:05] we are losing some capabilities like deleting
files. We are not doing those kind of actions.
[16:12] We can rename, but not delete. And it's bounded.
Every action that we do, bounded to a specific
[16:18] device, specific element in the network, and we're
not doing bulk actions or bulk configuration. So,
[16:27] if we're doing any mistake, it will stay contained
in a very small place in the one PC or something
[16:36] like that. So, the takeaways and if we can, you
know, go back to the questions, what it can do.
[16:45] Everything I told you, we know how to solve
incidents, we know how to connect to devices.
[16:50] We know how to run diagnostics and actions.
We sometimes will lose some capabilities and
[16:56] I suggest you guys to start small
and then expand the capabilities.
[17:01] The second one, what it should be allowed to do.
We solve it using permissions. So, if the user
[17:07] doesn't have permission to do something, the agent
won't be able to do that. We don't give the agent,
[17:13] you know, admin permissions and you know, it's not
in the God mode like some of our customers said.
[17:22] We're just letting him do exactly what the
user is allowed to do and reversibility. This
[17:27] is what happens when it's go wrong. If it's go
wrong, we know how to go go back and roll back
[17:33] to previous configuration and
that part is very important.
[17:40] So, if you can take one thing from this uh
presentation, if you're building AI agents,
[17:49] capabilities will always be there and you'll
get demand to add more and more capabilities
[17:55] over time, but if you want to do uh AI
agents at scale and with a good quality,
[18:05] the trust has to be structured in it. So,
think about it from day one and build it
[18:12] and answer the three questions that I mentioned.
Guys, thank you very much for listening.
[18:18] Come visit us at the booth, the pink
one, at Atera. Thank you very much.
