Ask Aribot from the assistant you already use

A security architect is in a design review when someone asks which threats are still open on the new booking flow. A compliance lead is drafting a board note and needs to say, in one sentence, where the company stands on the EU AI Act. An engineering manager knows there are critical findings on a service but not whether anyone owns them yet. In each case the answer exists. It sits in the security platform, behind a sign-in, three screens away from the conversation where it is needed.

So people either stop and go and look, which breaks the meeting, or they answer from memory, which is how stale numbers end up in board packs. Meanwhile the same people already have an AI assistant open all day, for writing, for code and for research. The obvious move is to let that assistant ask the security platform directly. The obvious risk is doing it badly: an API key pasted into a config file, an assistant that can reach more than the person using it, and no record afterwards of what it asked or did.

The Aribot connector is the careful version of the obvious move. Your assistant connects to Aribot over the Model Context Protocol (MCP), the open standard assistants use to call tools. You sign in once with OAuth. From then on the assistant can ask Aribot about your company, and only your company, with the same checks that apply when you click through the app yourself.

The connector is a second way into Aribot for people who already rely on it, or who should. It has no users of its own. These are the roles it serves most directly.

Aribot runs a remote MCP server at https://mcp.aribot.ayurak.com/. You give that address to your assistant once, in the place it keeps its connectors. For Claude that is Settings, then Connectors, then Add custom connector. ChatGPT takes the same address under its connector settings, Gemini can register Aribot as an OAuth 2.0 tool, and editors such as Cursor, VS Code and Windsurf take it as a remote MCP server. Claude Code can add it from the terminal with its standard claude mcp add command.

When you ask a question, the assistant decides which Aribot tool to call and with which inputs. The call goes to the MCP server, then through Aribot's governed gateway, the same one that checks every action taken in the app, and only then reaches your company's diagrams, scans, controls and tickets. The answer comes back the same way. Nothing in the chat is a copy of your whole estate; the assistant receives the result of the one call it made.

Signing in is where most assistant integrations cut corners, so it is worth walking through. When you add the connector, the assistant reads Aribot's published sign-in details and registers itself as a client for this connection. There is no client secret to copy and no key to store. It then creates a one-time PKCE challenge, a single-use proof that only the assistant which started this sign-in can finish it. That matters because it means an intercepted sign-in code is useless to anyone else.

You then sign in to Aribot in an Aribot window, with your usual account. You are shown what the assistant is asking for, such as reading findings and threat models, reading insights and coverage, starting scans or creating threat models. Only a company Owner or a Security Manager can approve. Once approved, Aribot issues access for that one company. The assistant never learns your password, and the access token can be revoked through Aribot's sign-in server.

Every tool call is answered from the company the connection was approved for. The assistant can do what the signed-in user can do in the Aribot app and nothing more: the same role, the same licence, the same company. If someone asks about a diagram that belongs to another company, it is not there for this connection. Aribot never looks the data up, so there is nothing to refuse.

This is also why the connector is safe to roll out to a whole team. A developer's assistant sees what that developer can see. A Security Manager's assistant can do what a Security Manager can do. Nobody gains a wider view by asking through a chat window.

These are some of the tools the Aribot MCP server offers, with the names your assistant sees. Most of them read. The ones that act go through the same approval rules as the app, and two of them, ticket filing and remediation, can be previewed before anything changes. Your assistant shows you which tool it is about to call, so you always know whether a question will read or act.

Kestrelmoor Freight is a fictional mid-sized logistics company with a customer booking portal, a route-planning model and a small platform team. Its security lead, Amara, connected Claude to Aribot last month. The approval took two minutes and she did it as the company's Owner.

At nine, the product director asks in the weekly review whether the new booking portal is safe to put in front of large customers. Amara types: summarise the threat model for our booking portal diagram. Claude calls get_diagram_summary with the diagram's id. The answer comes back in the conversation: two critical and six high threats, most of them on the public API gateway, two of them spoofing threats with no control mapped yet. The meeting moves on with an answer in hand, and nobody has to promise to check later.

At ten, the compliance lead, Joel, is writing the quarterly note to the board. He asks his own assistant, ChatGPT, connected to the same Aribot company: where do we stand on compliance across our frameworks? ChatGPT calls compliance_status. ISO 27001 and SOC 2 are mostly covered, DORA has open gaps in third-party risk, and the EU AI Act has gaps in record-keeping. Joel follows up about the route-planning model, and the assistant runs run_ai_governance_audit against the EU AI Act. Record-keeping and the human review step before a route is published are open, each with guidance. That paragraph goes into the board note, in plain words.

Before lunch, Amara asks Claude to raise tickets for the two critical threats, but to show her first. Claude lists the ticket destinations her role may use, then calls file_threat_tickets with a dry run. She sees exactly the two Jira tickets it would file, one per threat, in the booking team's project. She says send. The tickets are filed, and the next time anyone asks, the threats have owners.

One more thing happens that morning. A contractor with a Kestrelmoor account asks his assistant about a payment diagram he remembers from a previous client. There is nothing to find: his connection is for Kestrelmoor Freight, and the other company's diagram is not visible to it. Every one of these calls, the reads, the dry run, the filing and the empty result, is on the record in Aribot.

In the assistant, you see Aribot listed among your connectors, the tool it chose for each question and its inputs, and the answer in the conversation. For acting tools, you see the dry run before you confirm. If your plan reaches a limit, the assistant gives you a secure link to add credit or request a plan. You do not get a bare error.

In Aribot, nothing changes about where the work lives. Threat models, scans, compliance coverage and tickets are the same records the app shows. A ticket filed from a chat is the same ticket you would have filed from the threat list. The connector is listed in the official MCP Registry as com.ayurak/aribot-mcp, so it can be found and checked like any other public server.

Many teams meet Ayurak through the free AI readiness self-assessment, which shows in minutes where a company stands against the EU AI Act, the NIST AI RMF and related frameworks. Aribot is where that picture becomes engineering work: threat models of real systems, code and cloud findings, framework coverage and governed fixes. The connector is a doorway into Aribot from the assistant your people already use.

Ayurak Trust is where the evidence ends up: detailed, evidence-backed assessments, reviewed with Ayurak's team, using assessment templates by Aristiun built from official framework text. Answers given once satisfy several frameworks through crosswalks, and reports are tamper-evident. The answers your assistant gives from Aribot and the evidence your auditors see in Trust come from the same work, so the board note and the audit file agree.

The connection uses the Model Context Protocol for tool calls and OAuth 2.1 with PKCE for sign-in, both public specifications. The answers it gives map to public frameworks: the EU AI Act, the NIST AI RMF and ISO/IEC 42001 for AI governance; ISO 27001 and SOC 2 for security management; DORA for operational resilience; and NIST SSDF, OWASP and SLSA for secure software delivery. When your own agents start calling tools, the same gateway governs them; that is the subject of the MCP governance demo.