AI Agent Configuration Security

The configuration file is the security boundary for many AI agents. It names the tools the agent may call, the permissions those tools receive, where credentials live, and whether a person must approve a change. Foo Guard reviews that file. It does not wrap the running agent.

A secure agent configuration is specific. Read-only FAQ lookup is a different posture from a production tool that can publish content, call arbitrary URLs, and hold an embedded API key. Those differences are expressible in JSON or YAML, which means they can be reviewed like any other change.

The model Foo Guard actually evaluates

Foo Guard normalizes supported JSON and YAML into tools, permissions, credentials, autonomy, and auditability. Tool capabilities that affect findings include:

• executesShell for command execution
• accessesFilesystem and writes that change files
• arbitraryHttp for outbound network access
• accessesDatabase and database writes
• API credentials attached to the agent, including embedded and client-side keys
• Permissions that grant repository-style or production write, wildcards, or admin scope
• modifiesResources together with requiresApproval
• Autonomy fields such as iteration limits, unlimited autonomy, and human approval

Findings point at those fields. A tool named like a database client does not fail a rule unless the normalized capability says it can reach a database. Ambiguous scope strings are not upgraded into cross-resource access.

Examples that change the result

A production FAQ assistant with read-only faq.read, an environment variable for the model key, and human approval for escalation can scan clean. A staging support copilot that sets arbitraryHttp on an order lookup, or marks an OAuth credential longLived, produces findings for those declarations even when the rest of the file is careful.

An intentionally broad integration agent, with scope: "*", administrative: true, production: true, an embedded key, and a tool that both writes files and calls arbitrary HTTP, fails many rules at once. That combination is also why compound checks exist: modification plus network is a data exposure path, not two unrelated notes.

Secrets, sanitization, and what is stored

Credential rules look for secret material and for how a credential is placed: embedded in the document, shipped to the client, shared, or marked long-lived. Foo Guard does not verify that the secret is valid. It does not call the vendor.

An analysis you do not save is processed for that request and is not written to an account. When you save, Foo Guard stores a sanitized configuration snapshot and the deterministic findings. Values that look like secrets are redacted before storage. The same redaction applies before optional remediation is sent to the model. Remediation text is advisory. It does not change the score.

A review you can repeat

Before a configuration change merges, check four groups of fields. Identity and ownership tell you who is accountable for the agent. Credentials tell you whether a secret is in the file, on the client, shared, or marked long-lived. Tool capabilities tell you whether the agent can run a shell, write files, write a database, or call arbitrary URLs. Autonomy and auditability tell you whether a person must approve changes and whether actions are attributed in logs.

Foo Guard is the repeatable version of that review. The browser run is enough to see the findings. Saving the analysis keeps the sanitized snapshot and the score so a later edit can be compared. Comparison is available for saved analyses. It is not a runtime diff of two live agents.

From a file review to a gate

Configuration review in the browser is the starting point. The same model is what CI and GitHub checks evaluate, using thresholds from repository policy. Supported formats are documented in supported formats.

Foo Guard does not offer an IDE plugin that lints a buffer on each keystroke. Scan the file in the app, or scan the commit your pipeline already checked out.

Review an agent configuration