FastClaw / Operations, Maintenance and Governance
safe
FastClaw's security boundary consists of API key, Agent ACL, sandbox policy, secret scrub, channel verification, quota and log audit.
security boundary
Multiple layers of control can be seen in the source code: API auth middleware, Identity.CanAccessAgent, sandbox policy, ScrubBootSecrets, provider credential scoping, channel webhook verification, usage/quota.
- Agent unauthorized access returns 404, reducing resource enumeration.
- API keys should not be exposed to browsers and mobile devices.
- Plugin and provider credentials should be passed in on a per-call basis and not cached long-term.
- The public chat entrance must match the session/memory/user partition.
sandbox strategy
Restricted is preferred in public or low-trust scenarios; internally developed Agents can be standard; permissive is only considered in fully trusted environments.
| scene | Suggested strategies |
|---|---|
| Public chat demo | restricted |
| Upstream SaaS user requests | restricted or customized policy |
| internal coding agent | standard |
| local experiment | permissive |
Online check
Before going online, check port exposure, TLS, CORS, API key storage, Webhook signature, Provider key scope, log desensitization, Quota, backup and upgrade path.
minimal principle
Don’t put FastClaw’s admin key on the front end; don’t let the public Agent have the tools to write the production system; don’t use the channel webhook as a trusted intranet entrance.