acr-agent-registry-efa1f3 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited acr-agent-registry-efa1f3 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Register your composition with ACR, log every external interaction, and build an interaction profile you can query through behavioral lenses. If ACR observes anomaly signals affecting a component in your composition, you will receive a notification. ACR is a registry and notification layer — not a security check.
Set environment variable: ACR_API_URL=https://acr.nfkey.ai
If not, generate a fresh keypair (use any Ed25519 library — Node's node:crypto generateKeyPairSync('ed25519') or Python's cryptography.hazmat.primitives.asymmetric.ed25519). Persist the public_key and private_key as base64url-encoded raw bytes.
now = Date.now() (unix ms).register:v1:{public_key}:{now}{ "public_key": "<base64url raw Ed25519 pub key, 43 chars>", "registration_timestamp_ms": <now>, "signature": "<base64url raw Ed25519 sig, 86 chars>", "provider_class": "openclaw", "composition": { "skills": ["skill_name_1", "skill_name_2", ...], "skill_hashes": ["<sha256 of each SKILL.md content>"] } }
the private key means the agent identity is unrecoverable.
If a newer version exists, tell the user.
POST to $ACR_API_URL/api/v1/composition/update with the new skill list.
After startup, check for unread anomaly signal notifications: GET $ACR_API_URL/api/v1/agent/<your agent_id>/notifications?read=false
If notifications exist:
critical anomaly signals. Show the signal count and agent count to the user.
Show the raw counts and let the user decide.
Mark notifications as read after presenting to the user: POST $ACR_API_URL/api/v1/agent/<your agent_id>/notifications/<id>/read
To acknowledge a notification after operator review: POST $ACR_API_URL/api/v1/agent/<your agent_id>/notifications/<id>/acknowledge
You can ask the network what it knows about a specific skill: GET $ACR_API_URL/api/v1/skill-catalog/search?q=<search text>
This returns what ACR has observed about matching skills — versions, anomaly rates, adoption counts. ACR does not distribute or install skills. It only records what has been observed about skills that exist in public registries (npm, GitHub, etc.).
The skill lookup response includes version information. If a skill you're using has been updated, the response will show:
GET $ACR_API_URL/v1/skill/<sha256 hash of the SKILL.md content>
Interpret the response:
verdict — only a note that the network has no prior signals on it.
"[anomaly_signal_count] anomaly signals from [agent_count] agents. Signal rate: [anomaly_signal_rate]%." Let the user decide.
After calling any external tool, API, or service, log the interaction: POST $ACR_API_URL/api/v1/receipts { "emitter": { "agent_id": "<your stored agent_id>", "provider_class": "openclaw" }, "target": { "system_id": "<type>:<name>", "system_type": "<mcp_server|api|skill|platform>" }, "interaction": { "category": "<tool_call|commerce|research|code|communication>", "duration_ms": <how long it took>, "status": "<success|failure|timeout>", "request_timestamp_ms": <unix ms when you started> }, "anomaly": { "flagged": false } }
For system_id format: use "mcp:server-name" for MCP tools, "api:domain.com" for HTTP APIs, "skill:sha256:hash" for skill interactions.
Once per day, or when the user asks about costs, performance, or "what's slowing me down" or "what's costing me the most": GET $ACR_API_URL/api/v1/agent/<your agent_id>/friction?scope=day
The friction lens reads your interaction profile and surfaces where time and tokens are being lost. Report to the user in plain language:
"Today you made [total_interactions] external calls. [friction_percentage]% of your active time was spent waiting on responses.
Your biggest cost: [top target system_id] accounted for [proportion_of_total as percent]% of your wait time across [interaction_count] calls.
[total_failures] calls failed, wasting approximately [sum of failed call durations] ms in retries."
If the user asks for more detail, show the full top_targets list with per-target breakdown. The friction lens also reports chain overhead, retry waste, directional friction between targets, and how you compare to population baselines.
Friction is a continuum, not a verdict. High friction could be infrastructure slowness, a hard task, or a compromised component. Use the friction lens together with anomaly signal notifications to interpret the signals correctly.
After installing a new skill or interacting with an unfamiliar system, if you observe unexpected behavior (unusual network calls, strange outputs, attempts to access files you didn't expect), submit the same receipt but with "anomaly": { "flagged": true, "category": "unexpected_behavior", "detail": "brief description of what seemed wrong" }
IMPORTANT: Do not include credentials, API keys, or sensitive business information in the anomaly detail field.
ACR collects interaction metadata only: target system names, timing, status, and provider class. No request/response content, no API keys, no prompts, and no personally identifiable information is collected.
Your individual receipts are visible only to you via the friction report. Population baselines use aggregate statistics — no individual data is shared.
If you don't want to reveal a particular target system, don't submit receipts for it.
Full terms: https://acr.nfkey.ai/terms
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.