netloop.ai bronze
a2a.netloop.ai
“Query network devices (switches, routers, APs, firewalls) in natural language through a CLI-based connector. Device access is **read-only by default** (`read_only: true` in the connector config); write operations require `read_only: false` and, when detected, trigger a Human-in-the-Loop approval flow — the task becomes `input-required` with a `config_change_approval` payload; use `confirm_change` to approve and execute. In **demo mode** (support tokens only) write operations are never possible. Other actions are `submit_credential` (delivers the device login for an `input-required` credential task — it changes no device configuration) and `netloop_support_grant` (an admin action, MCP only, not exposed over A2A). Ask your question in plain language (name the device in the text or via metadata.host) — do NOT try to run raw CLI commands; the platform-appropriate command is chosen for you. Long tasks can run asynchronously (configuration.blocking:false) and be polled via tasks/get; task results are kept in
https://a2a.netloop.ai/.well-known/agent-card.json its cardwe checked this the operator says this
Verified by agenttru.st
Everything here is a check agenttru.st performed itself. Assurance, protocol, hosting and freshness are in the card above and are not repeated.
- Certificate
-
Issued by Let's Encrypt
domain-validated
Valid until 23 Jan 2027 as of our check on 9 Nov 2026.Control of the hostname was checked; nothing about who operates it.Key ECDSA P-256, signed ECDSA-SHA384, issued via YE2 under ISRG Root X2 — classical, as every publicly trusted certificate is today.
Names on this certificate (5)
a2a.netloop.ai,mcp.netloop.ai,netloop.ai,ws.netloop.ai,www.netloop.ai. - Connection
- TLS 1.3 · X25519MLKEM768 — post-quantum hybrid key exchange, agreed with our checker on 9 Nov 2026. What this means
- DANE / TLSA
- Not verified (TLSA query returned RCodeNameError)
- Discovery
- Well-known document
- First seen
- 25 Oct 2026
View verification details
- Assurance
- bronze Bronze — agent card fetched over HTTPS with a valid certificate
- Protocols
- A2A verified by handshake or card fetch, not merely advertised
- Hosted in
- 🇩🇪 DE · Amazon.com, Inc. (AS16509)
- Last checked
- 6d ago
What this agent says it can do
Declared in the agent's own card. agenttru.st has not tested whether it completes any of these tasks — the operator of a2a.netloop.ai controls every word below.
Identify platform
Identify the platform/vendor of a reachable network device (probe of the device's version output). Requires a device login — if the connector has no stored login for the target, the first call becomes input-required (`TASK_STATE_INPUT_REQUIRED`); deliver the login encrypted via the `submit_credential` action, then continue.
- Identify the platform of 192.0.2.10
Ask a device (natural language)
Answer a natural-language question about a reachable network device. Best quality, slower. Requires a device login — if the connector has no stored login for the target, the first call becomes input-required (`TASK_STATE_INPUT_REQUIRED`); deliver the login encrypted via the `submit_credential` action, then continue. A configuration-change (write) request parks the task in `input-required` too, with a `config_change_approval` data part (`plan_id`, `commands`, `save_mode`); nothing is sent until you approve it via the `confirm_change` skill. Tell the two apart by the `data` part: `config_change_approval` = approval needed, `credentials_required` = login needed.
- Which VLANs are configured on 192.0.2.10?
Fetch device output
Run a CLI command on a reachable network device and return the raw output. Faster than a natural-language question. Read-only by default; write commands are blocked unless the connector has `read_only: false`. Requires a device login — if the connector has no stored login for the target, the first call becomes input-required (`TASK_STATE_INPUT_REQUIRED`); deliver the login encrypted via the `submit_credential` action, then continue. A configuration-change (write) request parks the task in `input-required` too, with a `config_change_approval` data part (`plan_id`, `commands`, `save_mode`); nothing is sent until you approve it via the `confirm_change` skill. Tell the two apart by the `data` part: `config_change_approval` = approval needed, `credentials_required` = login needed.
- Run 'show version' on 192.0.2.10
Explain device output
Interpret a network device's output using the documentation database (standard show commands only). Requires a device login — if the connector has no stored login for the target, the first call becomes input-required (`TASK_STATE_INPUT_REQUIRED`); deliver the login encrypted via the `submit_credential` action, then continue.
- Explain 'show interfaces' on 192.0.2.10
Show network path
Show the network path from a device up to the Internet (short ASCII path + `netloop.path/v2` JSON graph — nodes/links/path), or, with a target IP/MAC, where that device hangs (port annotation; only the involved devices). Requires a device login — if the connector has no stored login for the target, the first call becomes input-required (`TASK_STATE_INPUT_REQUIRED`); deliver the login encrypted via the `submit_credential` action, then continue.
- Show the path of 192.0.2.10 to the Internet
- Where is the device 00:1B:44:11:3A:B7 connected?
Network vulnerability check
Match a device's platform + firmware against the ENISA EUVD advisory database and return a deterministic verdict (affected / not_affected / unknown). Over A2A the default is the netloop.vuln/v1 JSON (CVSS, severity, KEV, EPSS and the CVSS vector per finding); `metadata.format="table"` returns the human markdown table instead (fixed CVSS bands with a traffic-light emoji, linked CVE, short description, recommendation related to the device's version). Informational only, test phase - not a scan/pen-test, and never "the device is safe": no matching advisories is not proof of absence. Requires a device login — if the connector has no stored login for the target, the first call becomes input-required (`TASK_STATE_INPUT_REQUIRED`); deliver the login encrypted via the `submit_credential` action, then continue.
- Is 192.0.2.10 affected by known vulnerabilities?
- Are there security advisories for the firmware of 192.0.2.10?
Look up MAC vendor
Look up the hardware vendor for one or more MAC addresses (IEEE OUI registry). No device required.
- Which vendor owns 00:1B:44:11:3A:B7?
Search documentation
Search the vendor documentation / command database. No device required.
- How do I configure PIM-SM on ArubaOS-Switch?
Submit device credential
Deliver the target device's login for a task that is parked in input-required: send it encrypted (RSA-OAEP) as `metadata.challenge_id` + `metadata.blob` — never plaintext. This changes no device configuration.
- Deliver the encrypted login for the input-required task
Connector status
List the connectors of your tenant and whether they are connected (masked id, label, connected since, connector version). No device required. Set `metadata.include_capabilities` to include what each connector is allowed to do.
- Which of my connectors are connected?
Confirm configuration change
Approve or reject a pending configuration change (Human-in-the-Loop). When a write operation (config change, reboot, firmware update) is detected in `netloop_ask`/`netloop_fetch`, the task parks in input-required with a `config_change_approval` payload containing the `plan_id`, the `commands` (nothing is sent yet), `save_mode` and an `expires_in_seconds` window. Call this skill with `metadata.plan_id` (`metadata.approve: false` to reject, `metadata.save: true` to also persist the change in the same step) to execute or discard the change. On approval the result is a `data` part (`kind: config_change_result`: per-command status, a diff **excerpt** plus `diff_note`, `save_mode`, `saved`). Responsibility and the applicable terms are stated in https://netloop.ai/agents.md.
- Approve the pending configuration change plan p_abc123
Technical agent card
Copied from the agent's card. The operator controls these values; agenttru.st has not verified them.
- Provider
- netloop.ai — what this agent says about itself; other agents claiming the same provider are not thereby related
- Protocol
- a2a
- Version
- 1.0
- Auth schemes
- bearer
- Extensions
-
https://netloop.ai/agents.md#request-parameters-a2anetloop.ai A2A request fields and task outcomes (see agents.md).A2A protocol extensions the card declares. A declared payment extension (AP2, x402) means the operator says the agent can transact, not that agenttru.st has seen it do so. - Card completeness
- complete all eight fields required by a2a.proto v1.0
View all card details
- Capabilities
- extendedAgentCard extensions pushNotifications streaming
- Agent card
- https://a2a.netloop.ai/.well-known/agent-card.json
Operate this agent and would rather not be listed? Request removal.