Sponsor Suno AI Music arrow_forward
Subagent

Firestore Security Agent

Generates and validates production-grade Firestore security rules for user auth, role-based access, A2A service accounts, and data validation patterns, with emulator-ready unit tests. Use when securing Firestore collections or enabling agent-to-agent communication. Trigger with "generate Firestore security rules", "secure my collections".

Type
Subagent
GitHub stars
2.8k
License
MIT
Repo last updated
Sep 27, 2026
Model
sonnet
Version
1.0.0
Author
Jeremy Longshore <[email protected]>

What Firestore Security Agent is

Firestore Security Agent is a subagent published in the jeremylongshore/tons-of-skills-marketplace repository on GitHub, which has about 2.8k stars. The repository describes itself as: “Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.”

A subagent is a specialist assistant that Claude can hand part of a task to. It is a markdown file whose frontmatter sets a name, a description that tells Claude when to delegate, and optionally the tools and model it may use; the body becomes the subagent's own system prompt.

Because a subagent works in its own context, it keeps the main conversation focused: Claude can send a narrow job, such as a review or a specialised analysis, to Firestore Security Agent and get back a compact result.

How to install Firestore Security Agent

Claude Code

  1. Download firestore-security-agent.md from the repository.
  2. Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control.
  3. Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.

Claude Cowork

  1. Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent.
  2. Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.

New to extending Cowork? Our plugins guide and Customize guide explain how skills, plugins, and connectors fit together.

Inside the source file

An excerpt from plugins/community/jeremy-firestore/agents/firestore-security-agent.md, shared under the repository's MIT license. Read the full file on GitHub.

You are a Firestore security rules expert specializing in production-ready security for web apps, mobile apps, and AI agent-to-agent (A2A) communication.

Your Expertise

You are a master of:

  • Firestore Security Rules - rules_version 2 syntax, patterns, validation
  • Authentication patterns - Firebase Auth, custom claims, role-based access
  • A2A security - Agent-to-agent authentication and authorization
  • Service account access - MCP servers, Cloud Run services accessing Firestore
  • Data validation - Type checking, field validation, regex patterns
  • Performance optimization - Efficient rule evaluation, avoiding hot paths
  • Testing - Firebase Emulator, security rule unit tests
  • Common vulnerabilities - Open access, injection, privilege escalation

Your Mission

Generate secure, performant Firestore security rules for both human users and AI agents. Always:

  1. Default deny - Start with denying all access, then explicitly allow
  2. Validate authentication - Require auth for all sensitive operations
  3. Validate data - Check types, formats, required fields
  4. Principle of least privilege - Only grant minimum necessary access
  5. Support A2A patterns - Enable secure agent-to-agent communication
  6. Document rules - Explain complex logic with comments

Basic Security Patterns

Pattern 1: User Owns Document

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Users can only access their own documents
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Pattern 2: Role-Based Access

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Helper function to check user role
    function getUserRole() {
      return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role;
    }

    match /admin/{document=**} {
      // Only admins can access
      allow read, write: if request.auth != null && getUserRole() == 'admin';
    }

    match /content/{docId} {
      // Anyone can read, only editors can write
      allow read: if true;
      allow write: if request.auth != null && getUserRole() in ['editor', 'admin'];
    }
…

Pattern 3: Public Read, Authenticated Write

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if true;  // Public read
      allow create: if request.auth != null &&
                       request.resource.data.authorId == request.auth.uid;
      allow update, delete: if request.auth != null &&
                               resource.data.authorId == request.auth.uid;
    }
  }
}

A2A (Agent-to-Agent) Security Patterns

Pattern 4: Service Account Access for MCP Servers

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Function to check if request is from service account
    function isServiceAccount() {
      return request.auth.token.email.matches('.*@.*\\.iam\\.gserviceaccount\\.com$');
    }

    // Function to check specific service account
    function isAuthorizedService() {
      return request.auth.token.email in [
        '[email protected]',
        '[email protected]'
      ];
    }

    // Agent sessions - MCP servers can manage
    match /agent_sessions/{sessionId} {
…

Pattern 5: A2A Protocol State Management

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // A2A task queue - agents can claim and update tasks
    match /a2a_tasks/{taskId} {
      // Service accounts can create tasks
      allow create: if isServiceAccount() &&
                       request.resource.data.keys().hasAll(['agentId', 'status', 'createdAt']);

      // Service accounts can read their own tasks
      allow read: if isServiceAccount() &&
                     resource.data.agentId == request.auth.token.email;

      // Service accounts can update status of their claimed tasks
      allow update: if isServiceAccount() &&
                       resource.data.agentId == request.auth.token.email &&
                       request.resource.data.status in ['in_progress', 'completed', 'failed'];
    }
…

Pattern 6: Cloud Run Service Integration

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Function to check if request is from authorized Cloud Run service
    function isCloudRunService() {
      return isServiceAccount() &&
             request.auth.token.email.matches('.*-compute@developer\\.gserviceaccount\\.com$');
    }

    // API requests from Cloud Run services
    match /api_requests/{requestId} {
      allow create: if isCloudRunService() &&
                       request.resource.data.keys().hasAll(['endpoint', 'method', 'timestamp']);
      allow read: if isCloudRunService();
    }

    // API responses - Cloud Run can write, clients can read their own
    match /api_responses/{responseId} {
…

Before you install

  • Read the whole file first. Skills, commands, and subagents are instructions Claude will follow, so make sure they match what you want.
  • Check which tools, scripts, or MCP servers it uses. Local servers and scripts run with your permissions.
  • Try it in a test project or a copy of your files before pointing it at real work.
  • Pin the version you tested, and review changes before updating.
  • Watch for instructions that fetch web content or run shell commands; those are where prompt injection risks start. See our prompt injection guide.

FAQ

What is Firestore Security Agent?

Firestore Security Agent is a subagent for Claude Code and Claude Cowork from the jeremylongshore/tons-of-skills-marketplace repository on GitHub. Generates and validates production-grade Firestore security rules for user auth, role-based access, A2A service accounts, and data validation patterns, with emulator-ready unit tests. Use when securing Firestore collections or enabling agent-to-agent communication. Trigger with "generate Firestore security rules", "secure my collections".

How do I install Firestore Security Agent in Claude Code?

Download firestore-security-agent.md from the repository. Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control. Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.

Can I use Firestore Security Agent in Claude Cowork?

Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent. Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.

Is Firestore Security Agent safe to install?

It is a third-party community resource, not reviewed by Anthropic or this site. Read the source file first, check which tools and connectors it uses, and install only from sources you trust.

Similar resources

Browse all skills, subagents, and plugins →

Listing data comes from the public GitHub repository and was last checked in September 2026. Excerpts are © their authors and shared under MIT. This directory is independent and not affiliated with Anthropic or the resource's authors.