AI Agent Security Checklist for Private Assistants and Small Teams

AI agent security starts before Hermes gets tool access. For a founder, consultant, agency, or tiny team, the goal is not to make the assistant powerless. The goal is to limit blast radius, preserve human approval, and keep a clear record of what the assistant read, drafted, changed, and requested.

Secure Hermes by starting with one workflow, one owner, one runbook, scoped credentials, narrow tools, explicit stop conditions, and approval gates for high-risk actions. Add memory, skills, MCP servers, cron jobs, and write permissions only when the workflow needs them and the owner can review the result quickly.

The safest first setup is draft-first: the assistant may read approved context and prepare the next step, but it asks before sending, spending, deleting, publishing, merging, refunding, charging, or changing customer commitments.

Use least privilege by workflow

Do not give a general-purpose assistant your personal admin account. Create access around a specific role.

Examples:

• A lead assistant can read approved inbound sources and create reply drafts.
• A meeting assistant can read calendar events and project notes, then post a private brief.
• A support assistant can summarize tickets and draft responses, but not issue refunds.
• A content assistant can gather sources and prepare outlines, but not publish.

The assistant should have enough access to prepare useful work. It should not have enough access to cause silent damage.

Separate read, draft, and execute

Treat permissions in three levels.

1. Read: inspect approved sources.
2. Draft: prepare a reply, task, issue, summary, or change proposal.
3. Execute: send, delete, publish, merge, update records, charge, refund, or make commitments.

Most small teams should automate read and draft first. Execute belongs behind approval until the workflow has a clean history and low downside.

This framing also makes reviews easier. If something goes wrong, you can ask: did Hermes read the wrong source, draft the wrong action, or execute without the right gate?

Put approvals where the owner can decide

Approvals are not just a button. They are a decision packet.

A good approval message includes:

• source context;
• proposed action;
• exact output after approval;
• risk level;
• stop condition or uncertainty;
• who requested the action;
• where the receipt will be logged.

Example:

> Source: Gmail from Maya about a delayed invoice. Proposed action: send a polite payment follow-up draft. Risk: customer relationship. Stop condition: do not mention late fees. If approved: send this exact email and log the action in the daily owner summary.

A bare “approve?” message is too thin. The owner should not have to reconstruct context from three systems before clicking yes.

Keep MCP and plugin surface small

MCP and plugins expand what Hermes can touch. That is useful, but it is also more executable surface area.

Before adding a connector, answer:

1. What does this workflow need to read?
2. What does it need to change?
3. Which tools are unnecessary and should stay hidden?
4. Which actions require approval?
5. Where will the action be logged?

Add one connector, test it, document what it can do, then add another only if the runbook needs it. A meeting brief assistant probably does not need Stripe, GitHub write access, and full Gmail send authority.

Use the MCP catalog for vetted servers

Hermes ships with a curated MCP catalog - a manifest of Nous-reviewed servers like Linear and n8n. Catalog servers are inspected before inclusion, declare their source URL, and install with interactive credential prompts and tool-level permission whitelisting.

Install flow:

hermes update              # sync catalog manifests
hermes mcp                 # list available servers
hermes mcp install linear  # OAuth flow + tool checklist

During install, Hermes presents a tool checklist. You whitelist exactly which tools to expose (for example: find issues and create issues, but not delete workspace). This is principle of least privilege at the tool level.

Critical caveat: catalog entries never auto-update. You must run hermes update to sync new manifests, then hermes mcp install again to refresh. This prevents breaking changes from silently rolling out.

For custom MCP servers not in the catalog, use manual config.yaml configuration and apply the same scrutiny: read the source, understand the bootstrap commands, and start with read-only tool access.

Scope tool surfaces per profile

Each Hermes profile should carry only the tools it needs. A marketing assistant profile does not need GitHub write access. A finance assistant does not need social publishing tools.

Reduce the active catalog before scaling agents:

• List the tools a profile actually uses
• Remove or disable everything else
• Add MCP servers one at a time
• Test read-only calls first, then add write actions behind approval

A smaller tool surface makes routing cleaner and reduces accidental capability.

MCP calls flow through the same approval gates

MCP tools are still tools. Third-party MCP calls must pass through the same approval gates as built-in tools because they can touch external accounts and local systems.

If a workflow needs to post to Linear, publish via n8n, or push to GitHub via MCP, require explicit approval until the workflow has a clean history and low downside. Document which MCP actions are read-only, which are draft-only, and which require approval before execution.

Fine-grained credential scoping example: GitHub

When connecting GitHub via MCP, use fine-grained personal access tokens scoped to a single repository with only the permissions needed:

• Contents: Read and Write (for file edits and pushes)
• Issues: Read and Write (for creating and updating issues)
• Pull Requests: Read and Write (for creating and merging PRs)

Do not use classic personal access tokens that grant broad repo access. Fine-grained tokens limit blast radius to one repo and three permission types. Store the token in Hermes's secrets manager or .env, not in prompts, memory, or skills.

Treat credentials as operating controls

Use role-specific credentials instead of shared owner credentials.

Better names:

• lead-followup-assistant
• meeting-brief-assistant
• support-draft-assistant
• weekly-report-assistant

Named credentials make it easier to trace spend, revoke access, and isolate failures. If the weekly report assistant misbehaves, you should be able to revoke that role without breaking every other workflow.

Treat profiles the same way: as operating boundaries, not cosmetic labels. If two workflows need different memory, credentials, audience, approval rules, or model routing, separate them. A marketing assistant should not share the same keys and memory as a finance or production assistant.

Keep secrets out of prompts, memory, skills, and runbooks. Prompts describe behavior. Secrets belong in managed configuration or the platform’s approved connection layer.

Memory security: save less, save better

Persistent memory is powerful because Hermes can carry useful context across sessions. It is risky when it becomes a junk drawer.

Good memory candidates:

• stable owner preferences;
• durable business facts;
• preferred tone rules;
• lessons from repeated corrections;
• names of approved source systems.

Bad memory candidates:

• API keys;
• one-off customer messages;
• temporary project state;
• sensitive personal data that does not need to persist;
• unverified facts from a single conversation.

If a fact changes often, keep it in a system of record or current status file, not memory. If a fact is sensitive and not needed later, do not save it.

Skills security: procedures need stop rules

Skills make repeated workflows more reliable, but they can also preserve old mistakes. Every Hermes skill used for business work should include:

• purpose;
• inputs;
• allowed tools;
• blocked actions;
• approval points;
• output format;
• escalation rules;
• review date.

Do not create a skill that says “handle customer replies.” Create one that says “draft customer replies from approved support tickets, cite the ticket, and ask before sending, refunding, discounting, or changing status.”

Cron security: scheduled does not mean autonomous

Scheduled Hermes work should be boring and reviewable. Cron is good for reminders, digests, checks, and draft preparation. It is dangerous when it quietly performs irreversible actions.

Safer cron jobs:

• weekday owner briefing;
• Friday open-loop review;
• daily follow-up draft queue;
• weekly CRM hygiene report;
• monthly tool access review reminder.

Risky cron jobs:

• auto-sending customer messages;
• deleting records;
• issuing refunds;
• changing production systems;
• posting public content without review.

A scheduled job should say what it inspected, what it produced, what it skipped, and what needs approval.

Log receipts where humans already work

Every meaningful action should answer:

• what triggered the run;
• which sources Hermes used;
• what it drafted or changed;
• who approved it;
• what failed or was skipped;
• where the next follow-up lives.

Use the place the owner already checks: Slack, Telegram, email, CRM notes, a project tracker, a daily summary, or a simple log file. A receipt nobody reads is not an operating control.

Review and revoke on a schedule

Security decays when old experiments keep live permissions.

Review at least monthly:

• active workflows;
• connected tools and MCP servers;
• credentials and scopes;
• cron jobs;
• skills that still match reality;
• memory entries that should be removed;
• failed runs and near misses;
• approval actions that were too slow or too vague.

Remove access for abandoned workflows. Rotate credentials after role changes, connector changes, or security concerns.

First-week security plan

1. Pick one low-risk workflow.
2. Write the runbook before connecting tools.
3. Use role-specific credentials.
4. Start with read-only or draft-only access.
5. Add one connector at a time.
6. Require approval for all external actions.
7. Log every run in a visible place.
8. Review the first five outputs before expanding scope.

If the first workflow cannot fail safely, it is not a good first workflow.

Recap

Secure Hermes setups are narrow, visible, and approval-gated. Use scoped credentials, clean runbooks, small tool surfaces, careful memory, reviewed skills, safe cron jobs, and receipts. Expand access only after the workflow proves it can produce useful work and stop at the right boundary.

Next step

For implementation context, read Hermes Agent Runtime for Business Workflows. For the buyer-facing model, read Private AI Executive Assistant Setup Guide. To design the human-in-the-loop layer, read Approval-Gated AI Agents. If you want a done-for-you setup, start with Private AI Executive Assistant Setup.