Connecting an AI agent¶
CYBO Attest has an MCP server, so Claude and other AI agents can work with your applications the way you do in the console. An agent can read where each build stands, plan the fixes, start the scans, propose justifications and send a version toward review. It signs in as you and can do only what your own account can do.
The address is:
Connect Claude¶
- Open Settings, then Connectors, and choose Add custom connector.
- Name it
CYBO Attestand paste the address above. - Choose Connect. Your browser opens the CYBO Attest sign in page. Sign in with your usual account.
Any MCP client that supports remote servers and OAuth sign in connects the same way. The client finds the sign in page on its own from the address.
You sign in, the agent never sees a password
Sign in happens in your browser on the CYBO Attest sign in page. The agent receives a short lived token tied to your account. Repository tokens are never passed through the agent: adding a GitLab repository is done in the console, and the agent gives you the link.
What the agent can do¶
The agent can do what an engineer can do, narrowed to the permissions you grant when you connect.
| Permission | What it allows |
|---|---|
applications:read |
See your applications, their sources, configuration and justifications |
applications:write |
Add a GitHub repository, choose or fix a Dockerfile, request authorization, remove an application |
scans:read |
See scans, findings, base images, the fix plan and the security posture |
scans:write |
Start the scans of an application |
justifications:write |
Propose or withdraw a justification |
evidence:read |
Read each scanner's record, pipeline job logs and the review record |
Never through an agent: approving, rejecting or recording a decision on a build. That stays with a named Security Control Assessor in the console. Platform and organization administration also stay in the console.
Every change an agent makes is recorded with your name and the client that made it, for example mike via claude-code, so the record always shows who acted.
Before removing an application or withdrawing a justification, the agent asks you to confirm.
Things to ask¶
- "What is the security posture of my applications?"
- "Why is the newest build of my application blocked, and what is the plan to fix it?"
- "Which base image tag should my Dockerfile use?"
- "Explain finding 3 in plain words and draft a justification I can check."
- "Start the scans for my application and tell me when the verdict is in."
- "Request authorization for version 1.4.0."
The server also offers two ready made prompts: fix blocking findings and security posture report.
Tools¶
Reading:
| Tool | What it does |
|---|---|
whoami |
Who the agent is acting as |
get_security_posture |
The newest build of every container: state, verdict, failing gates, why it is blocked and the next action |
plan_fixes |
An ordered plan for one build: the base image tag to rebuild on, package upgrades, what must be fixed and what may be justified |
list_applications, get_application |
Your applications and their components |
list_intake_applications, get_application_progress |
Applications Attest set up for you, and the newest build step by step |
get_application_config, get_dockerfile_fix |
The cdso_config.yml Attest commits, and the corrected Dockerfile |
list_authorization_candidates |
Versions that can be sent for authorization |
list_justifications |
Justifications, active and withdrawn |
list_scans, find_scans, get_scan |
Scans, and one scan's gates, verdict and next action |
list_findings, get_finding, get_finding_change |
Findings, and the exact package change that fixes one |
explain_finding, draft_justification |
Explainable AI: what a finding means here, and a draft justification |
explain_gate, explain_gate_controls, explain_job, explain_assessment |
Explainable AI: a gate, its controls, a failed job, and the build impact assessment |
list_base_images, list_base_image_tags |
Approved base images and their tags |
get_scan_evidence, list_scan_jobs, get_scan_job_log, get_scan_artifact, get_scan_source, list_scan_runs |
The evidence behind a scan |
get_decision, get_review, get_review_summary |
Decisions and the review record |
get_github, list_github_repositories |
Whether GitHub is connected, and the repositories it reaches |
console_link |
The console page for work done in the console |
Changing:
| Tool | What it does |
|---|---|
start_scan |
Start the scans of an application |
choose_dockerfile, use_fixed_dockerfile |
Pick the Dockerfile, or build with the corrected one |
add_github_repository |
Add a GitHub repository as an application |
retry_provisioning |
Resume a setup that failed |
request_authorization |
Tag a version and send it toward review |
propose_justification, withdraw_justification, apply_justifications |
Justify a finding, withdraw a justification, commit them again |
remove_application |
Remove an application |
Bots and pipelines¶
A bot uses its own Keycloak client with client credentials instead of a person's sign in. Ask your administrator for a client; it can be limited to some applications. The bot then sends its token as Authorization: Bearer to the same address. See Roles and access.
Data the agent reads¶
The agent reads the same records you see in the console: applications, scans, findings, evidence, justifications and decisions in your organization, and nothing outside it. What it reads goes into your conversation with your AI client, under that client's own terms. Explainable AI answers are written by CERA, the model service Ulap operates, called as you; it keeps no prompts or answers. See the privacy policy, and write to support@ulap.co with any question.
Disconnecting¶
Remove the connector in your client's settings. Your administrator can also revoke the client in Keycloak, which ends its access at once.