Kiro + xCloud

Secure sites and servers with Kiro on xCloud

Securing sites and servers with Kiro means asking the agent in Amazon's IDE to read xCloud's vulnerability findings and server perimeter, with autoApprove and disabledTools in mcp.json deciding which security tools it may run without asking.

Skill: xcloud:servers
Toolsets: vulnerabilities, servers, sites, wordpress-actions
Free with every xCloud account

Set up Kiro All Kiro guides

YouWhich sudo users exist on Frankfurt? Flag any that look temporary.

servers_sudoUsers_indexread-only

AgentThree: deploy, ops and tmp-migrate. The last one looks temporary, going by its name. I can delete it, but I will name the server and the account and wait for your yes first.

YouLeave it for now, I will check with the team.

servers_firewall_ssh-restriction-statusread-only

AgentSSH is restricted to trusted addresses on frankfurt-1.

Last updated: October 2026. Keep a human in the loop: xCloud stops and asks before anything that creates, deploys, updates, reboots, deletes or buys.

Setup

How Do You Set Up Kiro to Secure sites and servers on xCloud?

Connect Kiro once; every job on this account uses the same connection. Then ask in plain words.

1
Add xCloud to your Kiro MCP config
Open the Command Palette (Cmd+Shift+P on Mac, Ctrl+Shift+P on Windows and Linux), search for MCP and choose Kiro: Open workspace MCP config (JSON) for .kiro/settings/mcp.json, or Kiro: Open user MCP config (JSON) for ~/.kiro/settings/mcp.json. Paste this, save, and Kiro reconnects on its own. The first connection opens the xCloud approval screen in your browser, where you tick the teams and choose Read-only or Full access.
JSON
```
{
  "mcpServers": {
    "xcloud": {
      "url": "https://app.xcloud.host/mcp"
    }
  }
}
```
2
Choose which xCloud tools Kiro may run
Optional. autoApprove lists tools Kiro runs without asking, and disabledTools hides tools from the agent altogether. The two names here are real xCloud tools; swap in your own. Avoid the "*" wildcard in autoApprove, so Kiro's own prompt stays as a second check beside xCloud's confirmation.
JSON
```
{
  "mcpServers": {
    "xcloud": {
      "url": "https://app.xcloud.host/mcp",
      "autoApprove": ["xcloud_docs_search", "xcloud_agent_search"],
      "disabledTools": ["sites_destroy"]
    }
  }
}
```
3
No browser sign-in? Use an API key
Create a token with the mcp:invoke scope plus the read abilities for the areas it will use (read:servers and read:sites, with read:billing and read:addons for billing and add-on tools) and the matching write: abilities if it should change things in Settings, Developers, API Tokens, export it as XCLOUD_API_TOKEN, and pass it in headers. Kiro only expands environment variables you have approved, so add XCLOUD_API_TOKEN under the Mcp Approved Env Vars setting. Never paste the token into the file or into chat.
JSON
```
{
  "mcpServers": {
    "xcloud": {
      "url": "https://app.xcloud.host/mcp",
      "headers": {
        "Authorization": "Bearer ${XCLOUD_API_TOKEN}"
      }
    }
  }
}
```

Check it worked

Then ask Kiro for the job itself, for example:

Prompt

Use xCloud to roll up vulnerabilities across all my sites and plan the fixes, worst first. Don't change anything yet.

In practice

How Does Security Work from Kiro?

Kiro is a good fit for this job because its MCP configuration lets you draw the line between reading and changing in a file, before any conversation starts. The xcloud entry in .kiro/settings/mcp.json can carry an autoApprove list and a disabledTools list, and security is where they pay off. Put the reads in autoApprove: sites_vulnerabilities_list, sites_vulnerabilities_count, servers_firewallRules and servers_fail2ban_banned-ips. Kiro then answers which of my sites have findings, or what is banned on Frankfurt, without a prompt for each call. Put the tools you never want the agent to see in disabledTools, for example servers_firewallRules_destroy and servers_sudoUsers_destroy, and deleting a rule or a privileged account is simply not an option in the chat.

That file-level control sits beside xCloud's own confirmation, not in place of it. Even with a tool in autoApprove, xCloud stops for an explicit yes before it bans an address, creates a rule or updates a plugin, so approve reads and leave the changes to the prompt. Because the entry can live in the workspace file or in your user file, you can also give one project its own security connection. A repository for an agency client can hold an xcloud entry that is authorized for that client's team only. With OAuth the file carries only the URL, so committing it does not leak a token, and the editor shows each tool call in the panel as it happens.

In the chat panel the flow reads like a conversation with a colleague. You ask for the team-wide rollup, Kiro calls vulnerabilities_index and lists the worst sites with the plugin or theme each finding names, and then it plans the fix: a sites_backup, a sites_wordpress_update after your approval and a rescan with sites_vulnerability-scan, which it checks again because a rescan finishes asynchronously. For the perimeter it reads the SSH restriction state and the sudo users, flags anything that looks temporary or unused, and gives you the dashboard path for the AI bot blocker and the 8G firewall, which are dashboard switches.

Kiro specific: MCP support has to be switched on in Kiro first: open Settings, search for MCP and enable the MCP support setting. If the same server name appears in more than one place, an agent config's mcpServers field beats the workspace file, and the workspace file beats the user file, so a stale xcloud entry can hide the autoApprove list you thought was in force. Review tool permissions before you add anything to autoApprove. Approve reads, and leave servers_fail2ban_ban, servers_fail2ban_unban, servers_firewallRules_create and the sudo-user changes out, so Kiro's own prompt remains a second check beside xCloud's confirmation. Avoid the wildcard in autoApprove for the same reason.

What xCloud does for security

xCloud reads vulnerability findings for one site or across your whole team, starts rescans and ignores or restores a finding. On servers it manages firewall rules, Fail2Ban bans, the SSH restriction state and sudo users. Protections such as the AI bot blocker, the 7G and 8G firewall and per-site IP rules stay dashboard switches.

Start with the team-wide rollup. For a fleet question the agent reads the vulnerability rollup across every site on the team in one call and sorts it worst first. For one site it reads the findings and the counts by severity instead.
Rescan and triage findings. A rescan runs without a confirmation stop and finishes asynchronously, so the agent checks the count again afterwards. Findings carry a severity and a source, and severity is the triage key. A false positive can be ignored with a reason and restored later.
Fix what the finding points to. Most findings are fixed by updating a plugin, a theme or WordPress core. The agent proposes the updates, takes a backup first if you want one, and waits for your approval, because updating plugins or themes always stops for confirmation.
Review the server's perimeter. The agent reads firewall rules, the Fail2Ban banned IP list, the SSH restriction status and the sudo users. It can add or disable a rule, ban or unban an address and whitelist xCloud's own IPs after you confirm the server and the effect.
Report what is dashboard-only. AI bot blocking, the 7G and 8G firewall and a single site's IP allow and block list are dashboard switches. The agent reads what it can, such as the 7G and 8G logs, and gives you the dashboard path and the site's dashboard link for the rest.

Reference

Security Settings and Limits on xCloud

The facts Kiro works within when it secures sites and servers. Where a row names the dashboard, that step stays yours to take there.

Setting or limit	What applies
Vulnerability findings	Per-site list and counts by severity (critical, high, medium, low), plus a team-wide rollup across every site you can reach
Rescans	Triggering a rescan is a routine action that runs without a confirmation stop. It is asynchronous, so the agent polls the count or the site events
Ignore and restore	A finding can be ignored with a reason and un-ignored later. Both are changes to the finding, not to the site
Firewall rules	List, create, enable, disable and delete server rules by name, protocol (tcp or udp), traffic (allow or deny), port and optional source IP
Fail2Ban	List banned IPs, ban one or more addresses and unban an address. Adding addresses to Fail2Ban's own ignore list is an SSH step described in the Fail2Ban guide
Whitelisting	xCloud's infrastructure IPs and the caller's IP can be whitelisted. The SSH restriction status says whether SSH is limited to trusted addresses
Sudo users	List, create or update, and delete OS-level privileged accounts. Private keys are never returned, and a temporary account is available for short jobs
7G and 8G firewall	Switched on in the dashboard. Their logs are readable through the nginx log type of the site's access log read
AI bot blocker	A dashboard toggle: Site, Tools, Nginx and Security on Nginx, Tools, Security on OpenLiteSpeed
Per-site IP rules	Dashboard-only: Site, Tools, IP Management. The API lists a site's rules but does not change them; server-wide blocks are on the API
Automated security updates	xCloud installs security updates on servers it provisions, and Automatic Reboot restarts the server only when a reboot is required. Both are configured in the dashboard
Security headers	The API lists a site's custom Nginx configuration. Adding headers is a dashboard or SSH step, described in the security headers guide

Rules Kiro has to follow

Firewall, Fail2Ban and sudo-user changes name the exact server and the effect before they run, and they wait for your yes. Locking out SSH is the risk the agent explains first.
The agent never disables SSH or a database service to tidy up a ruleset, and it does not delete the default SSH rule on its own.
Updating a plugin or theme to fix a finding stops for your approval, and the agent offers a backup first.
Ignoring a finding needs a reason you give. The agent records it and tells you how to restore it.
AI bot blocking, the 7G and 8G firewall, per-site IP rules and automated update settings are dashboard steps. The agent says so, gives the path and the dashboard link, and never claims it changed them.
A temporary sudo user is for a specific job and is removed when the job ends.

Example prompts

What Can You Ask Kiro to Do for Security?

Type these as written and swap in your own repository, site and server names. Reads and routine actions such as backups, cache purges, PageSpeed scans and vulnerability scans run straight away; creating, deploying, updating, rebooting, deleting, buying or starting a broken-link scan stops and asks first.

Prompt

Use xCloud to roll up vulnerabilities across all my sites and plan the fixes, worst first. Don't change anything yet.

Prompt

List the sudo users on the Frankfurt server and flag any that look temporary or unused.

Prompt

Check the SSH restriction status and the firewall rules on Frankfurt, and tell me what you would tighten before you tighten it.

Prompt

Show the vulnerability count for every site on this team, sorted worst first, and name the top three findings.

Prompt

Run a vulnerability scan on the shop site and tell me what it finds.

Prompt

List the findings on the blog site and ignore the false positive in the contact form plugin, with the reason.

Prompt

Update every plugin on the shop site, then run a vulnerability scan, and stop if anything is still open.

Prompt

List the firewall rules on the Frankfurt server and tell me whether SSH is restricted to trusted IPs.

Prompt

Show the IPs Fail2Ban has banned on the Frankfurt server, and unban 203.0.113.10.

Prompt

Whitelist the xCloud IPs on the Frankfurt server.

Prompt

Which sudo users exist on the Frankfurt server? Flag any that look temporary or unused.

Kiro and Security: Frequently Asked Questions

What people ask before they let Kiro secure sites and servers through xCloud.

Which xCloud tools should I put in Kiro's autoApprove list for security checks?

Only reads, such as the vulnerability list and count, the firewall rule list and the Fail2Ban banned-IP list. Leave ban, unban, rule creation and sudo-user changes out so Kiro still asks. xCloud also stops for confirmation before those changes, which gives you two checks.

Can Kiro be stopped from deleting firewall rules or sudo users?

Yes. List the delete tools, such as servers_firewallRules_destroy and servers_sudoUsers_destroy, under disabledTools on the xcloud entry in mcp.json. Kiro then hides them from the agent altogether, so the chat cannot call them even if you ask.

Can an agent show vulnerabilities across all my sites at once?

Yes. xCloud has a team-wide rollup that lists findings for every site you can reach, which the agent sorts worst first. For one site it reads the findings and the counts by severity, and it can start a rescan.

Can the agent ban an IP address on my server?

Yes. It can ban addresses in Fail2Ban, list the banned IPs and unban one, and it can create, disable and delete server firewall rules. It confirms the server and the effect first, so you do not lock yourself out.

Can the agent turn on the 8G firewall or the AI bot blocker?

No. Both are dashboard switches. The agent can read the 7G and 8G firewall logs through the site's nginx logs, and it tells you where the switches are: the site's Tools section. It does not claim to have changed them.

Can the agent block an IP for just one site?

Not from here. Per-site IP allow and block lists are managed in the dashboard under Site, Tools, IP Management, and the agent can only list what is there. Server-wide blocks, through firewall rules and Fail2Ban, are on the API.

Does the agent fix a vulnerability on its own?

No. It reports the finding and proposes the update that remediates it, usually a plugin, theme or core update. Updates always stop for your approval, and the agent can take a backup first and rescan afterwards to confirm the finding is gone.

Other agents