From AI finding to fix, with the proof.

Finding AI risk is the first half of the job

Most organisations can now produce a list of AI problems. A scan finds a model key in a repository. An agent turns out to hold a permission it has never used. A cloud account has a storage bucket open to the internet, and the service behind it feeds a model. The list grows faster than anyone works through it, and each open item keeps its exposure while it waits.

The second half is the hard part. Each finding needs an owner, a decision and a change that sticks, and afterwards someone has to be able to show what was done. Spreadsheets of findings tend to stall at the owner step. Automated fixes that nobody can explain stall at the audit.

Discovery and remediation in Aribot covers both halves. It takes what discovery finds about your AI systems, your agents and the access they hold, and gives each item a route to a fix: an action on the agent, a fix through a remediation plan or governed self-healing, or, for a threat, a ticket in the tracker your team already uses. Each decision goes into the audit trail, so when someone asks later what was found and what was done about it, the answer is a record.

Who this is for

Fixing AI risk crosses teams. Security sees the finding, the AI team owns the agent, platform owns the account and compliance has to sign off the result. Each of them works from the same findings and the same record here.

Where the findings come from

Four kinds of finding feed remediation. Each has its own screen in the product, with the detail its owner needs. They share a route from finding to decision to record.

Shadow AI

Discovery looks across the repositories you connect, and can also look at network traffic, for model endpoints, vector databases, agent frameworks and AI provider keys left in code. Each finding shows the provider, the model, the file and line, a risk level and an owner. More on the shadow AI page.

The agent fleet

Every agent under governance is assessed against the authority it holds and the authority it uses. An agent that could not be assessed stays on screen as exactly that, and is never counted as clear. More on the agent governance page.

Cloud findings

Cloud account scans raise findings against your policies: storage open to the internet, keys that never rotate, logging switched off on the service that feeds a model. Each account gets its own remediation plan.

Code findings

Threat models, code scans and the check on each pull request raise threats where the code lives. The pull request check comments on the change and fails it on critical or unverified threats. See pipeline security and code review.

Findings carry the evidence that raised them. A shadow AI finding points to a file and line. An agent finding names the permission and the threat it is linked to. A cloud finding names the resource and the policy. Nobody has to rebuild the context before deciding what to do.

The agent actions queue

When the fleet assessment finds an agent that needs a decision, it goes to the actions queue under Agent governance. The queue is grouped by the action to take, worst first. Each row is one agent and one check, with the reason in plain words, for example that the agent holds a permission linked to a high-risk threat, and a link to that agent's full assessment.

Audit an AI system against the frameworks

Some findings only appear when a whole system is held up against a framework. The AI governance audit takes an architecture diagram or a code scan and checks it against the EU AI Act, DORA, the NIST AI RMF and ISO/IEC 42001. It works article by article and returns the controls that are satisfied, the gaps that are open and remediation guidance for each gap.

You can run it from your own AI assistant. Connect Claude, ChatGPT, Gemini or an IDE assistant to Aribot over MCP, sign in with OAuth, and ask in your own words. The assistant sees your company's data with your permissions, and nothing else.

The same assistant can ask Aribot for a remediation plan for a threat or finding as a dry run: the proposed steps come back after Aribot's governed checks, and nothing is changed. When you ask it to apply a fix for real, the fix goes through the same checks as any other, including whether the attack path is reachable, your autonomy policy and your approval flow. If your policy needs an approval, the answer is that approval is required, and nothing is applied.

For a system in scope of the EU AI Act, the gaps feed the conformity dossier described on the EU AI Act readiness page. The audit is evidence for your people's decisions. It is no legal advice, and classification and sign-off stay with them.

Remediation plans for each cloud account

Cloud findings come in volume, and fixing them one at a time hides the pattern. The remediation plans view shows the whole company and each account side by side. A strategic plan for an account sets out the root causes behind its findings, the high-impact actions with their priority and effort, the phases to do them in, and how you will know it worked.

Policy fixes sit in a table with their status, filterable by severity, with a count of how many are done. A plan made before the account's latest scan is marked as older than the scan, so you generate it again against current findings. Commands in a plan that would delete or overwrite something carry a warning label. They stay visible, because the plan put them there for a reason, and the label makes sure they are read before they are run.

When a list cannot be loaded, the screen says it could not be loaded, which is a different message from an empty list. A missing plan never looks like a finished one.

Tickets in the tracker your team already uses

A lot of AI risk is fixed in code, by the team that owns it, in its normal sprint. Aribot files threats as tickets into Jira, GitHub, GitLab, Azure DevOps or ServiceNow, along the routes your administrators set up for each project.

• Preview the exact tickets before anything is sent, and see a warning when the destination is a public repository.
• One ticket per threat per report. Asking again reports the ticket as already filed, so nobody gets duplicates.
• The current state and assignee of open tickets are pulled back into Aribot, so the finding shows who is on it.
• The same actions are available from an AI assistant over MCP, with the same permissions as the person signed in.

On pull requests, the Aribot check leaves one comment that updates as the change moves on, so the developer sees the threat where the fix will be made.

Proof in the audit trail

Remediation that cannot be shown did not happen, as far as an auditor is concerned. Agent decisions in Aribot are written to a tamper-evident audit trail: the action, who took it, when and the reason. Fixes keep the record of the gates they cleared. Tickets keep their state.

Anyone with the right access can re-check the trail at any time. If a record was changed after it was written, the re-check shows where. The honest promise is detection, and detection is what an auditor can test. More on the AI audit trail and cost page.

A week at Marrowgate Freight

Marrowgate Freight is a fictional logistics company with a route-planning service, a quoting agent, a customer support assistant and cloud accounts for analytics. Here is its first week with discovery and remediation.

1. Monday
   Discovery runs across the code

   Marrowgate Freight connects 140 repositories. Shadow AI discovery returns nine findings. Two matter most: an AI provider key committed to the configuration of the route-planning service, and a vector database added to the customer support pipeline that nobody registered. The platform team takes the key, the support team takes the database, and both findings now have an owner.

2. Tuesday
   The fleet assessment fills the queue

   Of 31 agents under governance, four need an action and six could not be assessed because their permissions carry no labels. The quoting agent holds a permission to export every customer record, linked to a high-risk threat. The security lead applies Block from the queue and records why. A scheduling agent with the same problem is in the middle of a run, so the queue recommends Reduce access. The AI team lets the run finish, then removes the permission where it is issued. The six unassessed agents get labels by the afternoon and are checked again.

3. Wednesday
   An AI governance audit of the support assistant

   The AI lead asks Claude, connected to Aribot over MCP, to audit the support assistant's architecture diagram against the EU AI Act. The audit lists satisfied controls and three open gaps, including how long conversation logs are kept and how a person can take over a conversation. Each gap comes with remediation guidance, which the AI lead turns into work for the next sprint.

4. Thursday
   Fixes clear the safety gates

   The remediation plan for the analytics cloud account traces most of its findings to one root cause: a storage bucket that serves model training data is open to the internet. The fix is low impact, clears every gate and is applied with its record. Rotating the shared service key behind the same pipeline is higher impact, so it waits. The head of platform approves it for the evening change window.

5. Friday
   Tickets for the rest, and a re-check

   Six threats from the support assistant's threat model need code changes. They are previewed, then filed to Jira, one ticket per threat. A repeat request reports them as already filed. By the afternoon two are in progress and their assignees show in Aribot. The compliance lead re-checks the audit trail, exports the action queue for the risk register and adds the evidence to the company's ISO/IEC 42001 assessment on Ayurak Trust.

Marrowgate Freight, its people and every number in this scenario are invented for illustration.

Decide where people stay in the loop

Remediation goes wrong in two ways: nothing gets fixed, or something gets fixed that should have been left alone. Each part of Aribot lets you choose how much happens without a person.

At the agent gateway, start in watch-only mode. Every call is checked and recorded and you see which ones would have been blocked, but nothing is stopped. Switch to enforce when the list of would-have-blocked calls holds only the calls you want stopped. In the actions queue, applying is limited to administrators. In self-healing, you set the impact level above which a person must approve. Tickets put the change in the hands of the team that owns the code.

Whichever path a finding takes, the decision and the person behind it are on record.

Standards this supports

Remediation is where most frameworks ask for proof. Here is what each one expects and where you will find it.

Framework names are used to describe what the product supports. This page is no legal advice.

Questions teams ask

What happens when we apply Block?

The agent is cut back to its minimum permissions and its session is cleared, so its next call through Aribot is refused. The decision, who made it and the reason go into the audit trail. Sessions the agent holds in other systems end only when sign-out signals to your identity provider are set up. The confirmation says this before anything is applied, so nobody believes an agent is stopped everywhere when it is stopped at one place.

Can every queue action be applied from the queue?

Today Block can be applied from the queue. For the other actions the queue shows why there is no apply button, in the platform's own words, and your team makes the change where the permission is issued. The queue still records the finding and you can export it.

An empty queue: does that mean our agents are safe?

Only if every agent was checked. The queue always shows how many checked agents need an action and how many could not be assessed. If some could not be assessed, the empty state says so and tells you what to do next: add permission labels or issue a permission, then check again.

Will self-healing change production without asking?

Only within the line you set. Low-impact fixes can apply on their own once they clear every gate. Higher-impact fixes wait for a person to approve them. If a gate cannot reach a verdict, the fix does not go ahead.

Which trackers can tickets go to?

Jira, GitHub, GitLab, Azure DevOps and ServiceNow. You can preview the exact tickets before anything is sent, each threat gets one ticket per report, and the current state and assignee are pulled back into Aribot.

Can we run the AI governance audit from our own AI assistant?

Yes. Connect Claude, ChatGPT, Gemini or an IDE assistant to Aribot over MCP and ask it to audit a diagram or a code scan. It sees only your company's data, with the permissions of the person signed in.

Is the audit a legal opinion?

No. It shows where a system meets a framework's requirements and where the evidence is missing, with guidance for each gap. Classification, legal interpretation and sign-off stay with your people and your advisers.

What does the audit trail prove?

That a record has not been changed since it was written. Anyone with access can re-check the trail, and a record altered later would show up on the re-check. That is the claim an auditor can test.

Where do we start?

Most teams start with the free AI readiness self-assessment, then connect repositories and agents to Aribot in watch-only mode. Book a call and Ayurak's team will walk through your first discovery run and your first queue with you.

Start with the free self-assessment. Go deeper with evidence.

1. Step 1, free

   Answer the AI readiness self-assessment online. You get a view of where you stand against the EU AI Act, the NIST AI RMF and related frameworks, in minutes.

2. Step 2, with Ayurak's team

   A detailed, evidence-backed assessment on Ayurak Trust: each answer supported by evidence, reviewed with our team, and reported in a form you can hand to a board or an auditor.