Most of the code shipping today passes through an AI agent on its way to production. The developer asks, the agent writes, the developer reviews, the build goes out. Every security tool the developer has to use sits outside that loop, in a console they have to open, read, and act on by hand. The agent that wrote the code cannot see the findings. The person who has to fix the findings has to leave the place where the work happens.
At Ulap we built CYBO Attest so that every build is verified, every finding is explained, and every release is approved by a named person who understood it. Starting this month, all of that record, and every action short of the approval, is open to the AI agents developers already use. Connect Attest to Claude, Claude Code, GitHub Copilot, Cursor, the Gemini CLI, ChatGPT, OpenAI Codex, or any other agent that speaks the Model Context Protocol, and the agent can read the findings, apply the fix, draft the justification, start the rescan, and bring the case to the reviewer, under the developer's own permissions. Here is what that means, what the agent can and cannot do, and why the person on the decision gets faster, not slower.
The problem nobody plans for
Most of what a security process asks a developer to do happens between scans. Read the worklist. Understand a finding that was written by a scanner for another scanner. Work out which package pulled in the vulnerable one. Change the base image. Rewrite the Dockerfile. Write a justification for the finding that cannot be fixed yet, in words an assessor will accept. Rescan. Check that it worked.
Every one of those is a trip to a console, and the trip is the cost. The finding lives in one window, the code in another, and the developer carries values between them by hand. An agent that could do most of that work is sitting in the terminal, but it cannot see the console, so it cannot help.
Meanwhile the review process on the other end was built for code written by people at a human pace. More code, written faster, by agents, with the security work still done by hand in a separate tool, is a bottleneck that gets worse every month.
What we opened, and how
The Model Context Protocol is an open standard that lets an AI agent call tools from an outside service, the way it already calls the file system or a compiler. Attest now publishes its tools at one address, and the server is listed in the official MCP Registry as app.ulapcybo/attest, so clients that read the registry find it by name. Any agent that supports the protocol connects to that address, sends the developer to the Attest sign in page in their browser, and from then on can work the Attest record on that developer's behalf.
Nothing about Attest moved. The console, the pipeline, the gate policy, the reviewer's queue, and the posture page are the same. What changed is that the same record and the same actions are reachable from the chat window or the terminal the developer already has open.
Grouped by stage, the agent can register a repository and choose which Dockerfile to build; scan the latest code after a fix, which pulls the newest commits, rebuilds the container, and runs the scans, and follow it to its verdict; list findings, explain any one of them in plain language, and give the exact manifest line that moves a vulnerable package to its fixed version; get the ordered fix plan and the corrected Dockerfile, and apply it; draft a justification an assessor can score, submit it, or withdraw it; and read posture against the gates, see which versions are ready, and request authorization.
Approving or rejecting a build is not on that list, and it never will be. It stays in the console with a named person.
Four rules the integration follows
To be trusted with the record, an agent has to work under rules a reviewer can check. These are the four.
- It signs in as the user. The first time an agent connects, the developer's browser opens to the Attest sign in page. The agent receives a short lived token tied to that account and never sees a password. It can see and do exactly what that person can see and do in the console, and nothing more. If a developer cannot see an application, their agent cannot either.
- It inherits the explanation and the fix plan. Every finding carries the reasoning Attest's Explainable AI produced from the scan record: what it is, why it matters in this container, and what closes it. An agent with the repository open takes that reasoning and says which file and which line it applies to. That is the gap between a package name and a patch.
- Every write is logged with a name. Every change an agent makes is recorded with the person's name and the client that made it, for example
mike via claude-code. Before anything that changes state, the agent asks. The reviewer sees the same package they would have seen if the developer had done everything by hand, with the same trail behind it. - It cannot approve. Approval is withheld by design. Approve and reject are not exposed as tools, to any client, with any permission. A build that passes every scan is complete and ready for a reviewer, and nothing about it is approved until a person reads the case and signs under their own identity.
What it looks like in practice
A developer has a build blocked on a handful of findings. In Claude Code, inside the project directory, they ask the agent to get the Attest fix plan for the application and work through it top to bottom, one commit per fix, then run the tests, start a scan, and confirm the findings they fixed are gone.
The agent pulls the plan. It names the approved base image to rebuild on and the package versions to move to, in order, so the agent applies the plan instead of guessing at it. It edits the Dockerfile, bumps the packages, runs the tests, and the developer reviews the diff before anything is committed. Once the fix is pushed, the agent asks permission to scan the latest code; Attest pulls the new commits, rebuilds the container, runs the scans, and the agent follows the build to its verdict. The new scan shows the findings closed, and that build is the one the reviewer sees. For the one finding that cannot be fixed yet, the agent drafts the justification from the finding's own evidence, the developer edits it, and it is submitted under the developer's name.
A team lead opens Claude on a phone before a review meeting and asks which applications are ready to request authorization and which gates the others are failing. Read only, no approvals, answered in seconds from the same record.
A pipeline runs a read only posture check after every build, and a scan on every merge to the main branch, with only the tools it needs allowed and the write tools held back unless the job exists to perform that action. A bot that cannot sign in through a browser gets its own identity from the Attest administrator, limited to the applications it is allowed to touch, and its writes are logged under its own name like anyone else's.
In every one of those cases the case that reaches the reviewer is the same case. It arrived faster, and it arrived complete.
Where it plugs in
One address, and as of this week eight agents from five companies have passed the same test against it: connect and sign in, ask who you are, ask for posture, ask for a finding explained, ask for a scan and confirm the agent asks first, disconnect. Each one signs in as the person and none of them can approve.
Claude, on any device. Add Attest once as a connector and it follows the account to the web, the desktop app, and the phone. The connection runs from Anthropic's side, not the laptop, so it works from a locked down corporate network.
Claude Team and Enterprise. The Owner adds Attest once for the organization and each member clicks Connect and signs in with their own Attest account. Nobody shares credentials, and the organization decides which tools are available.
Claude Code, in the terminal and in the cloud. One command for an individual. Add it at project scope and the repository carries the connection, so every teammate who clones it, and every cloud session that opens it, has Attest from the first prompt, each signed in as themselves.
GitHub Copilot, in VS Code and in the terminal. Copilot Chat in Agent mode connects to the same address, so the agent that is already editing the file can read the finding that applies to it. The Copilot CLI shares the same configuration, so adding Attest in either one makes it available in both.
Cursor. Add the address in Cursor's MCP settings and click Login. The agent in the editor reads the finding that applies to the file it already has open, applies the fix plan, and starts the rescan, under the developer's own account.
Gemini CLI. Google's terminal agent adds the server with one command and signs in through the browser. For teams whose tooling is Google's, the record is the same record.
ChatGPT. Add Attest as a connector with its address and sign in. The questions a team lead asks before a review, which applications are ready and which gates the others are failing, are answered in ChatGPT from the same record, read only, no approvals.
OpenAI Codex, in the terminal and the IDE. One command adds the server, one signs in, and Codex works the same findings, fix plans, and justifications as the others.
Research. In Claude's Research mode the agent calls Attest on its own across a long run: which findings recur across every application, and which base images cause them, is dozens of read calls and one answer. Leave the write tools off for research sessions.
CI and scheduled jobs. A read only posture check after every build, a scan on every merge to the main branch, a posture summary posted to the team channel each morning. Each job is allowed only the tools it needs, and the write tools stay off unless the job exists to perform that action.
Bots with their own identity. A pipeline that cannot sign in through a browser gets its own client from the Attest administrator, limited to the applications it may touch. Its writes are logged under its own name, the same as a person's.
The API, for everything else. Every tool the agent calls is one of the 34 documented API operations, so anything that is not an agent, a dashboard, a ticketing integration, a script, reaches the same record the same way.
The person still decides. Faster.
The objection to a named person on every release is that people are slow. They are slow when they have to dig. The reviewer was never the bottleneck; the digging was. Attest removes it. Its Explainable AI organizes the whole pipeline by application, explains every finding and gate, plans the fix, drafts the justification, and lays out the review so the assessor sees every finding with its fix or its justification, the evidence trail, and the exact next step in one place. The artifacts, the issues, the fixes, and the justifications arrive centralized, consolidated, and summarized, and the reviewer is told what to do next rather than left to work it out. The agent integration does not change any of that. It moves the developer's side of the work to where the developer already is, so the case is prepared sooner.
What the reviewer gets is unchanged: transparent, because they can see how every conclusion was reached, with lineage from commit to pipeline to merge request to decision; and traceable, because every item links back to its evidence and every decision records who made it and when. Whether a person or an agent did the fixing, the reviewer reads a finished case, understands it in minutes, and decides with confidence. The agent works at its pace, and the person on the decision keeps up.
That is the whole point of putting the record in front of the agent. Not to take a person out of the decision, but to make sure that by the time the decision arrives, the digging is already done.
Connecting it
Each client takes a few minutes. In Claude, add Attest as a custom connector with its address, sign in, and ask for your applications. In Claude Code, one command adds the server and the sign in happens in the browser; add it at project scope and every teammate who clones the repository gets the connection and signs in with their own account. In VS Code with Copilot, one click installs it and Copilot Chat in Agent mode uses it, and the Copilot CLI picks it up from the same configuration. In Cursor, add the address in the MCP settings and click Login. In ChatGPT, add a connector with the address and sign in. In the Gemini CLI and in Codex, one command adds the server and one signs in.
Other agents that support the protocol connect to the same address the same way. Before we publish a guide for one, it passes the same short test every client gets: connect and sign in, ask who you are, ask for posture, ask it to explain a finding, ask it to start a scan and confirm it asks first, disconnect. Each client that passes gets its own page next to the Claude guide.
The click by click guides, with what the agent can and cannot do and a troubleshooting table for each client, are at docs.ulapcybo.app/ai-clients.
This is in production today
The agent integration is part of the October Attest release, alongside exact fix guidance on every finding, Explainable AI on findings and justifications, a complete review record, and 34 documented API operations. It is available on every Attest account, including early access, at no extra cost. The agent runs under whatever AI subscription the developer already has.
Attest runs on the pipeline Ulap helped develop with Army Cyber to automate the scanning, testing, and approval of containerized software for IL5 and above. ARCYBER reported an authorization timeline cut from seven months to about two hours on that pipeline (March 2026). The record an agent now works is the same record that produced that result.
Who did the work, and who decided?
The question for any team putting agents into its pipeline is simple. When a build goes out, who did the work, and who decided it could run? If the answer to both is the agent, nobody decided. If the answer to the first is the agent and the answer to the second is a person who understood the case, you have Attest.
Early access to CYBO Attest is open at ulapcybo.app/early.html.