autobotAI is a factory for security agents. Your team designs, builds, runs and governs every agent in one place, and every agent shares the same integrations, guardrails and audit trail. You don't assemble a new stack for each use case, so the hundredth agent is as governed as the first.
This page explains the parts of the factory and follows one risk from the moment it's found to the moment it's proven closed.
The factory at a glance
| Part | What it does | Learn more |
|---|---|---|
| Optimus and AI Builder | Describe the job in plain language. Optimus does ad-hoc work now, or assembles a harness of agents working toward a goal. AI Builder drafts workflows on the canvas that you can read step by step. You can also start from the library or build node by node. | Investigate with Optimus, Build with AI Builder |
| Agents, workflows and harnesses | The work itself: deterministic workflows, AI agents that reason over many steps, and harnesses that combine both around one goal. | Agents, workflows and harnesses, Workflow or harness? |
| Integration layer | 1,000s of integrations, federated. Agents query each tool where the data lives, at the moment they act. | Integrations and your data |
| Context | Memory spaces, skills and your organization's knowledge: owners, approvers, policies and how your assets relate. | Memory spaces, Skills |
| Guardrails | Autonomy set per action by risk, approvals in Slack, Microsoft Teams, email or your ticketing tool, and role-based access. | Autonomy and approvals |
| Proof | Every execution, decision and approval on the record, re-tests that confirm fixes hold, and a live register of every risk. | Guardian, Audit trails |
| Where it runs | SaaS, or self-hosted in your own AWS account. Any model, chosen per agent. | Architecture and security, Deployment and models |
From detected to closed
Most security tools stop at the finding. The work that follows (who owns it, what the fix is, who approves it, whether it shipped, whether it held) is where risk stays open. autobotAI is built for that part.
Validating Mermaid syntax...
Take a critical vulnerability in an internet-facing payments service:
- The finding arrives. A scanner, cloud security tool, SIEM alert or your own red-team agent reports it. Listeners and schedules start the right agents.
- Agents enrich it where the data lives. They query the cloud account, the code repository, the asset inventory and threat intelligence directly, without copying logs into another store.
- They work out who owns it. Context from your knowledge base and memory spaces names the service owner, the approver and the escalation path.
- The fix arrives ready to approve. Depending on the layer, that's a pull request with the code change, a WAF rule in count mode, a firewall change, a cloud-posture change routed to CloudOps, or a dependency upgrade tested in a lower environment first.
- A named person decides. The approver gets the evidence, the proposed change and the alternatives in Slack, Microsoft Teams, email or the pull request, and approves, rejects or changes it.
- Agents follow through. If the fix isn't shipped within its SLA, the agent follows up with the owner and escalates to the next approver.
- The fix is proven. A re-test confirms the exposure is gone. A WAF rule moves from count to block only once the logs show it doesn't break legitimate traffic.
- The register stays live. The risk register records the finding, the decision, who made it and the evidence, so audit evidence is a by-product of the work.
The same loop applies across SOC, GRC, identity, AppSec, cloud, IT and network teams: an access review, a phishing report and a misconfigured bucket all move through it.
What stays in your control
- Scope. Agents can only use the integrations, actions and workflows you give them.
- Autonomy. You decide, per action, what runs on its own and what waits for a person. See Autonomy and approvals.
- Data. Run self-hosted and the agents, credentials, execution history and audit trail stay in your AWS account. See Architecture and security.
- Models. Use the model provider you already trust, and a different model for each kind of task.
Next steps
- Quickstart: set up autobotAI and run your first workflow.
- Agents, workflows and harnesses: choose the right shape for a job.
- Optimus: build agents by describing the job.
- Platform components: what to use where: every building block and when to use it.