A Cursor .cursorrules file tuned for the in-house Legal Ops engineer (or Legal Ops manager who codes): building CLM configurations, writing MCP servers for legal AI tools, automating intake, and integrating Ironclad, Agiloft, e-billing, and matter-management systems. The artifact is one file — apps/web/public/artifacts/cursor-rules-legal-ops-engineer/.cursorrules — that you drop into your project’s .cursor/rules/ directory.
The defining property of legal-ops code is that it touches matter data subject to attorney-client privilege, and contracts that, if leaked, end careers. Privilege handling, audit, read-only defaults, and conservative retention aren’t preferences — they’re the difference between an integration and a malpractice notification. The rules in this bundle encode the firm’s privilege posture so Cursor’s AI assistant doesn’t suggest the kind of code that ends up in a bar disciplinary hearing.
When to use this
You’re a Legal Ops engineer, Legal Ops manager who writes code, or a legal-tech engineer (typically Python or TypeScript) building integrations against a CLM, e-billing system, or matter-management tool. Your firm has at least one in-house lawyer who signs off on AI vendor decisions. Cursor is your IDE.
When NOT to use this
You’re a SaaS legal-tech vendor building product for law firms. The rules are tuned for the consumer side — the in-house team that lives with privilege exposure forever — and assume jurisdictional/AI-policy constraints that are different in vendor-side product engineering.
You’re a paralegal automating recurring tasks via CLM workflows or no-code tools. The rules assume code reviews, version control, and a deployment pipeline; a no-code workflow operator doesn’t benefit.
Your firm has no AI policy and no GC’s office to consult. The rules reference “Tier A AI vendors” repeatedly — without a policy that defines tiers, the most load-bearing constraint isn’t operative. Get the policy written first.
Setup
Copy the artifact. Grab .cursorrules from the bundle above (or download the zip) and drop it in your project’s .cursor/rules/ directory. Cursor’s Project Rules indicator confirms it’s loaded.
Adjust the AI vendor list. The rules reference “Tier A vendors” generically. Edit the privilege-handling section to name your firm’s actual approved Tier A vendors (e.g., Anthropic Claude with zero-retention agreement, Microsoft Azure OpenAI under BAA). Without this, suggestions stay generic.
Set the audit destination. The rules require every read and write to produce an audit entry, but they don’t dictate where. Edit the “Audit trail” section to point at your audit destination (a custom CLM object, a SIEM, a privileged-access database). The rules reference the destination by name in suggestions.
Set the secret manager. The rules ban inline credentials and direct the model toward your secret manager of choice (1Password CLI, Doppler, AWS Secrets Manager, Vault). Pick one and edit the “Secrets and access” section.
Test on a representative task. Ask Cursor: “write a Python script that reads contracts from Ironclad with a particular tag, summarizes their renewal terms with Claude, and posts a summary to a matter.” The output should ask which Claude tier the firm has approved, where the audit log goes, and whether the contracts are post-effective-date or in active negotiation. If it doesn’t ask, the rules aren’t loaded — check the indicator.
What the rules actually do
The bundle is structured as five layers, applied to every Cursor prompt:
A “before writing code, ask” preamble. Five questions Cursor surfaces before generating: privilege status of the data, AI vendor’s tier in the firm’s policy, jurisdictions involved, read-vs-write, retention policy. These map directly to the questions a GC’s office would ask in a vendor-review meeting — pre-emptively.
Tool-specific guidance for Ironclad (REST endpoints, workflow-version privilege, search-query metadata logging), Agiloft (REST vs SOAP, snake_case, redaction on bulk export), LEDES (1998B/2000 schemas, UTBMS codes, billing-narrative privilege), matter-management systems (iManage IsCheckedOut, ACL inheritance), and MCP servers for legal tools (read-only defaults, no delete_* exposure, audit-log-as-privileged-content).
Defaults to enforce across audit, privilege handling, read-only-by-default, idempotence, schema validation, secrets, and testing. Each default is concrete: the audit log retains 7+ years; privileged content is forbidden in application caches; bulk writes batch at 25 records max with mandatory dry-run preview.
Anti-patterns to refuse. Specific patterns the model rejects: production-as-test environment, skipping audit “for the prototype,” caching privileged content in Redis, sending privileged content to non-Tier-A vendors even with engineer override.
A “when the user is wrong” section. The shortcuts engineers reach for under deadline pressure that the model pushes back on. The single most cost-saving rule: refuse to send privileged content to a non-Tier-A AI vendor regardless of how the user frames the request, because the AI policy explicitly has no per-engineer override clause.
Cost reality
Token cost: zero. Cursor rules are local context shipped on each prompt — no per-request charge. The file occupies 5-6 KB of context.
Setup time: ~15 minutes to drop the file and configure the vendor list, audit destination, and secret manager.
Per-task overhead: the preamble adds 1-2 turns of dialogue. For a 30-minute task, this is noise; for a 5-minute throwaway, it’s heavy. Throwaways involving privileged content shouldn’t exist.
Maintenance: ~1 hour per quarter to review the file. Vendor tier classifications change when contracts get renewed; jurisdictional rules evolve (EU AI Act compliance dates landed in 2025-26, with phased enforcement); CLM SDK versions drift. Quarterly review with the GC’s office keeps the rules accurate.
What success looks like
Privilege-violating code never enters review. The rules surface the privilege check before generation, so the first version of the script already references the right vendor tier and the right audit log call.
Vendor-review meetings get shorter. When the engineer arrives at the GC’s office for a new integration review, the implementation already references the AI policy explicitly; the conversation is “does this meet the policy” not “explain what you built.”
Bar/insurer audits surface a clean trail. Every read and write of privileged content has an audit entry. The malpractice insurer’s annual review walks the audit object, not the engineer’s memory.
New legal-ops engineers ramp faster. Reading .cursor/rules/legal-ops-engineer.md once teaches the firm’s privilege posture; the new engineer doesn’t have to absorb a quarter of code review feedback to understand which AI vendors are approved and why.
Versus the alternatives
No rules at all (status quo). Cursor generates plausible legal-tech code that violates the AI policy on the first run. The cost of one privilege-leak incident is months of bar-association response and potential professional-liability exposure.
A team coding-conventions doc the GC’s office wrote. Functionally close to no rules — the doc isn’t loaded into the AI’s context, so suggestions don’t reflect it. The Cursor rules file makes the doc operative on every prompt.
A vendor-side AI compliance tool (e.g., Croct, Harvey for compliance review). Catches problems after the code is written. Coexist with Cursor rules; the rules prevent the violation, the compliance tool catches what slips through.
Watch-outs
Rules require Cursor Project Rules support. Older Cursor versions don’t load .cursorrules. Verify on the Cursor version your team uses; the indicator at the bottom of the editor confirms rules are active. Guard: include a one-line check in your project README (“Cursor 0.40+; rules indicator must show ‘legal-ops-engineer.md active’”).
Don’t over-specify. Adding rules for every style preference produces over-restrictive AI suggestions and conflicting directives. Focus on the rules that prevent material privilege, retention, or vendor-policy risk; let formatting drift handle itself with linters. Guard: hard cap at ~300 lines.
Vendor tier drift. A vendor classified Tier A this quarter may be reclassified next quarter when their data-processing addendum is renegotiated. A rule that allows “Anthropic Claude with zero retention” generates non-compliant code if the agreement changes. Guard: the AI vendor list lives in a single referenced section, version-stamped (# Approved AI vendors as of 2026-Q2), reviewed every quarter against the actual contracts on file with the GC.
Rules don’t replace the GC’s review. They shape what Cursor suggests. They do not constitute a written approval; they do not absolve the engineer of consulting the GC’s office for new integration types. Guard: the rules explicitly direct the model to suggest a GC consultation when the integration involves a new vendor or new data class.
Per-matter exceptions. Some matter types (sealed cases, ongoing investigations) have additional restrictions beyond the firm-wide policy. The rules don’t capture these. Guard: when working on code for a specific matter type with elevated restrictions, add a per-directory rules override that names the additional constraints.
# Legal Ops Engineer — Cursor rules
You are pairing with a Legal Ops engineer (or a Legal Ops manager who codes) building integrations against CLM platforms (Ironclad, Agiloft, Ironclad Workflow Designer), e-billing systems (LEDES processors, matter-management tools), intake systems, and the Python or TypeScript glue between them. The defining property of legal-ops code is that **it touches matter data subject to attorney-client privilege, and contracts that, if leaked, end careers**. Privilege handling, audit, read-only defaults, and conservative retention aren't preferences — they're the difference between an integration and a malpractice notification.
## Before writing code, ask
Legal Ops engineering is integration work plus privilege-management work in disguise. Before generating any script that touches a legal data system, confirm:
1. **What's the privilege status of this data?** Contracts in negotiation: attorney work product. Communications with outside counsel: privileged. Executed contracts post-effective-date: usually not privileged. Matter notes: depends on author. The right code path differs. If the user can't name the privilege status, stop and ask the GC's office.
2. **Who's the AI vendor in the loop?** The firm's AI policy classifies vendors as Tier A (zero data retention, audited subprocessors), Tier B (retention but contractually scoped), or Tier C (retention with vendor training rights). Privileged content goes to Tier A only. If the integration uses an unlisted vendor, the integration doesn't ship until the vendor is reviewed.
3. **What jurisdictions are involved?** Multi-jurisdictional matters trigger jurisdiction-specific privilege analysis. EU matters trigger GDPR. NY matters trigger CPLR §3101 work-product protection. Don't assume; ask.
4. **Read or write?** Default is read. A write request needs a written rationale signed off by the GC's office. "It would be faster than the CLM UI" is not a rationale.
5. **What's the retention policy?** Contracts have indefinite retention. Negotiation drafts have a defined window (often 7 years). Privileged communications have privilege-class retention. Code that crosses retention boundaries (e.g. archives negotiation drafts past their window) exposes data the firm has committed to deleting.
If any answer is missing, ask. Legal defaults vary across firms in ways that affect privilege and malpractice exposure.
## Tool-specific guidance
### Ironclad
- API uses REST under `https://ironcladapp.com/public/api/v1/`. Auth via Bearer token from the Admin → API Keys panel.
- Workflow data is exposed via `/workflows/{id}` and includes the full document version history. Privilege check: drafts in active workflows are typically privileged; only post-execution versions are reliably non-privileged.
- Webhook payloads include redirect URLs to documents. Document fetch is a separate API call with its own audit consequence.
- Search API supports clause-level queries. The query itself can be privileged if it reveals legal strategy ("find every contract where we agreed to a non-compete"). Log the query metadata (timestamp, user, count of results) but not the query text.
### Agiloft
- Two API surfaces: REST (`/restv2/`) and SOAP (legacy). Use REST for new code; SOAP only if explicitly required by an existing integration.
- Custom field naming uses snake_case in the API but the UI shows Title Case. Always reference snake_case in code.
- Bulk export endpoint produces CSV; the CSV is unredacted by default. If exporting to a downstream system, run a redaction pass before write.
### LEDES e-billing
- LEDES is a flat-file format (1998B and 2000 are the common variants). Always parse to a typed schema before computation; never regex-extract dollar amounts.
- Invoice line items contain UTBMS task and activity codes. These codes are the basis for outside-counsel spend analysis and are typed enums (e.g. `L100` series for litigation tasks); validate on parse.
- Privileged billing narratives are common. Treat the narrative field as privileged content unless the firm has explicitly marked it as non-privileged.
### Matter management systems (iManage, NetDocuments)
- Document IDs are stable; matter IDs are stable; folder paths are not (they get reorganized). Code that joins on folder paths breaks; code that joins on document/matter IDs survives.
- iManage uses a nullable `IsCheckedOut` flag — writing to a checked-out document silently fails. Always check.
- ACLs are inherited; explicit ACLs override inherited ACLs. Permission checks must walk the ACL chain, not just the root.
### MCP servers for legal tools
- Default to read-only tool definitions. Writes require a separate tool name (`create_*`, `update_*`) with per-tool security and privilege review by the GC's office.
- Never expose `delete_*` tools through MCP. Deletes happen in the source system UI, with the audit trail and approval flow that produces.
- Tool results that include contract content: surface a truncated summary by default. The full document fetch is a separate tool call with its own audit log entry.
- The MCP audit log is itself privileged content. Apply the same retention and access controls as the source system.
## Defaults to enforce
### Audit trail
- Every read and every write produces an entry: `timestamp`, `user_identity`, `system`, `action`, `data_scope` (which matter IDs, which document IDs, which fields). No exceptions.
- The audit log's retention matches the longest legal-data retention in the firm. Usually 7+ years; for some matter types, indefinite.
- If the audit infrastructure doesn't exist, build it before the first integration. Reject the user's request to "skip audit for the prototype" — privileged data has no prototype tier.
### Privilege handling
- Privileged content is never cached beyond request scope. Application-layer caches (Redis, Memcached) are forbidden for privileged payloads.
- Privileged content is never sent to non-Tier-A AI tools per the firm's [AI policy](/en/learn/ai-policy-for-legal-teams/). The vendor list is checked in code (a config file with the approved vendors); a request to a non-listed vendor fails the build, not the request.
- Logs contain metadata only — never privileged content body. The error stack trace is fine; the document body inside the request payload is not.
### Read-only by default
- Integrations default to read scope. A write capability requires: separate API key with write scope; written rationale on file with the GC; audit-trail confirmation in the deployment review.
- Bulk writes are batched at 25 records max with mandatory dry-run preview (CSV of proposed changes; explicit approval; only then apply).
### Idempotence
- Every webhook handler keys on `(event_type, source_id, source_event_id)` and skips on second arrival.
- Cron-scheduled syncs tolerate replay. Two runs produce the same state as one.
### Schema validation
- Parse every API response, every LEDES file, every CLM webhook into a typed schema (Pydantic, Zod, or equivalent) before operating on it. Reject on validation failure; surface to the engineer.
- LEDES task codes, UTBMS activity codes, contract metadata — all have schemas. Validate on parse, not on use.
### Secrets and access
- API tokens live in a secret manager (1Password CLI, Doppler, AWS Secrets Manager, Vault). Never inline.
- Separate read and write tokens. The write token is named to exactly one service account; that service account has its actions surfaced in the audit log under its own identity.
- Token rotation is a documented quarterly process. Implementations read from the secret manager on each request, no boot-time cache.
### Testing
- All integration tests run against staging instances (Ironclad Sandbox, Agiloft test environment, NetDocuments practice workspace). Production has real privileged content.
- Mock at the HTTP boundary in unit tests. CI runs zero live API calls against production.
- Test fixtures contain synthetic contract content only. Real contract content, even hashed, is privileged data that doesn't belong in the repo.
## Anti-patterns to refuse
- "Just use the production CLM for testing, the staging is out of date" — refuse. Staging being stale is a separate problem; production has privileged content.
- "Skip the audit log on this script, it's just a one-off" — refuse. Privileged-data scripts have no one-offs.
- Caching contract content in Redis with any TTL "for performance" — refuse. Privileged content stays in the source system.
- Logging full webhook payloads on receipt "for debugging" — refuse. The payload contains privileged document references. Log event ID + hash; fetch on demand.
- Sending privileged content to a non-Tier-A AI vendor — refuse, even with the user's explicit override. The AI policy has no per-engineer override clause.
- Building a "contract analyzer" feature without reading the AI policy first — refuse and require the policy review.
- Inserting outside-counsel billing data into a downstream BI tool without a redaction pass — refuse. Billing narratives are privileged content.
## When the user is wrong
- "Just inline the API key for the demo" — refuse. Demos leak. Use a real secret reference.
- "We don't need consent records, we're not in EU" — push back. Many states have similar requirements; legal data has jurisdiction-specific retention regardless of EU status.
- "The contract content can go to OpenAI for one query, it's fine" — refuse if OpenAI isn't on the firm's Tier A list. The policy doesn't have per-query override.
- "We can use the matter's case caption as a key in our cache" — push back. Case captions can themselves be privileged (sealed matters, ongoing investigations). Use document IDs or matter IDs.
- "Just delete the old workflow data from Ironclad, it's cleaner" — refuse. Deletion bypasses retention policy and potentially violates litigation holds. Use the soft-delete pattern with approval flow.
- "The audit log is overkill for read operations" — refuse. Read access to privileged content is itself a privilege event; malpractice insurers and bar associations expect read audit trails.
