autobotAI is federated by design. Agents don't need every log copied into one place before they can act. They query each tool where its data lives, at the moment they need it, through one integration layer shared by every agent you build.
Federated, not centralized
Centralizing every log in one store means paying to move and keep data that is already in the tools that produced it, and the copy is often hours behind. Agents that act on a risk need the current state, not yesterday's copy.
| Centralize first | Federated with autobotAI | |
|---|---|---|
| Where data lives | Copied into one store | Stays in each source tool |
| Freshness | As old as the last ingest | Current, read at the moment of action |
| Cost | Ingest and retention for every log | Queries only what the agent needs |
| Coverage | Limited to what was ingested | Any tool with an integration or an API |
This works alongside the tools you already run. Your SIEM, XDR and data lake stay exactly where they are and become sources agents can query like any other. Nothing has to be replaced, and nothing has to be moved first.
Ways to connect
| Method | Use it for | Learn more |
|---|---|---|
| Native integrations | 1,000s of maintained integrations across cloud, identity, security, code, ITSM, messaging and observability tools | Integrations |
| Listeners | Receiving events and webhooks, such as findings, alerts and CI/CD signals, to start workflows | Listeners |
| Linux and Kubernetes agents | Reaching systems inside private networks; the agent needs only outbound HTTPS | Linux agent, Kubernetes agent |
| Generic REST API | Any service with a REST API, with bearer token, basic or API key authentication | Generic REST API |
| Python | Your own logic, with pre-authenticated clients for the integrations you've connected | Python, Actions |
Once a tool is connected, every agent and workflow you allow can use it. You connect it once, not once per use case.
Credentials and scope
- You grant the scope. Each integration uses the credentials and permissions you provide. Give read-only access where agents only need to investigate, and add write access only for the actions you plan to approve.
- Least privilege by default. Integration guides list the minimum permissions each one needs.
- Credentials stay in your workspace. In a self-hosted deployment, integration credentials, execution history and audit logs are stored in your own AWS account. See Deployment and models.
- Actions code never handles secrets. Python actions receive authenticated clients from the platform rather than raw credentials.
- Test before you rely on it. Each integration can be tested from the Integrations page after you save it.
Browse integrations
- AI models: Amazon Bedrock, OpenAI, OpenRouter, Ollama and more.
- Cloud: AWS, Azure, Google Cloud and their security services.
- Identity: Microsoft Entra ID, Okta, CyberArk, SailPoint and Saviynt.
- Security tools: EDR, vulnerability management, threat intelligence, DLP and email security.
- Code and CI/CD: GitHub, GitLab, Bitbucket and Azure DevOps.
- Messaging and ITSM: Slack, Microsoft Teams, Jira, ServiceNow and more.
Don't see a tool? Most can be connected through the Generic REST API the same day, and our team adds native integrations on request.