Advanced agent configuration & MCP

At enterprise scale the model is a commodity; the configuration is the differentiator. Anyone can install Cursor. The FDE earns their seat by turning a sharp tool into a governed, repeatable system: standards encoded once, context wired in safely, and execution power clamped to least privilege.

Think in three planes that every agent interaction passes through. Knowledge: what the agent knows about your standards (Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. / AGENTS.md). Context: what the agent can see outside the repo (MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.). Capability: what the agent is allowed to do (command allow/blocklists, hooks, terminal sandboxing, isolation). Get those three right and autonomy becomes a dial you can turn with confidence instead of a leap of faith.

Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. are how you stop re-explaining your codebase to the model on every prompt. You write your style, test, and architecture standards once; they live in the repo, version-controlled, and every agent interaction in that scope inherits them automatically.

The mechanism: rules live under .cursor/rules/ (scoped, area-specific files) and the repo-root AGENTS.md (the open, portable convention for agent instructions). Because they are files in git, they get code review, blame, PR history, and rollback — the same lifecycle as any other source. That is the whole point: standards become an artifact, not tribal knowledge in someone's head or a Slack thread.

Scope rules to the area they governglobal vs. nested

Don't dump everything into one mega-rule. A root AGENTS.md carries org-wide invariants (language, security posture, 'never touch generated files'). Then nest area-specific rules next to the code they apply to — a stricter rule file in services/payments/ can demand 100% branch coverage and forbid new external calls, while web/ gets component conventions. The agent inherits the union, with the nearest scope winning. This is least-knowledge applied to standards: each subsystem teaches the agent exactly what it needs.

services/payments/.cursor/rules/payments.md — nested, area-scoped, version-controlled
# Payments service rules
- All money is int cents; never float.
- Every new endpoint requires a contract test + an idempotency key.
- No new outbound network calls without an entry in ALLOWED_EGRESS.md.
- Follow the repository pattern; controllers must not import the DB client.
- Example to imitate: see charges/create_charge.py

Most of what an engineer needs to do a task well lives outside the repo: the Jira ticket, the Confluence runbook, the Datadog dashboard showing the error spike, the internal API docs. MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. (Model Context Protocol) is the standard bridge that lets the agent reach that context — and the artifact graph is what it exposes through that bridge.

MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. is an open protocol: an MCP server wraps a system (Jira, Confluence, GitHub, an observability platform, an internal docs service) and exposes its data and actions as tools the agent can call. Instead of you copy-pasting a ticket into the chat, the agent queries the Jira MCP server directly, reads the acceptance criteria, and links the PR back. The repo stops being an island.

Why the FDE cares: context quality drives output quality

An agent that can see the ticket, the design doc, and the live error trace writes a fundamentally better fix than one guessing from the diff. MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. is the difference between 'autocomplete with extra steps' and 'a teammate who actually read the context.' But every server you connect is also a new trust boundary and a new data path — which is exactly why it must be governed.

Governing allowed MCP serversallowlists, not free-for-all

• MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. allowlist — admins specify which MCP servers are permitted org-wide; developers can't wire in an arbitrary server that ships data to who-knows-where.
• Scope per server — prefer read-only scopes for context-only servers (Confluence, docs); reserve write/action scopes (creating Jira tickets, posting to Slack) for servers that genuinely need them.
• Privacy posture — remember Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. + ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. govern what leaves to the model; an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server is a separate data path you must reason about independently.
• Audit — MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. calls are part of the activity you want logged so you can answer 'what external systems did agents touch, and when?'

Knowledge and context shape what the agent says. Capability controls govern what it can execute — and that's where blast radiusHow much breaks if a change goes wrong; the scope of potential damage. lives. The principle is the same one you'd apply to any service account: least privilege, deny by default, log everything.

The four capability controls

Stack these, don't pick one. A mature setup uses allowlists to define the vocabulary of permitted actions, hooks to enforce policy on those actions, sandboxing to contain local execution, and VM isolation to contain autonomous/async execution. Each layer assumes the one above it can fail.

There is no single 'agent.' There's a ladder of surfaces from near-zero autonomy to fully headless, and each rung needs guardrails matched to its blast radiusHow much breaks if a change goes wrong; the scope of potential damage.. The mistake teams make is applying laptop-grade trust to async, multi-repo execution — or, worse, starting at the top.

Notice the inversion: as the human leaves the loop, the configuration has to carry the trust the human used to provide. At rung 1 a typo is nothing; at rung 6 a misconfigured egress rule is an incident. So guardrails don't stay constant up the ladder — they intensify in lockstep with reach.

Once an agent reads external content (a web page, a Jira comment, an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.-sourced doc), that content can contain instructions. Prompt injection is the agent equivalent of SQL injection: untrusted input smuggling commands into a privileged context. You defend by assuming any non-repo content is hostile and clamping what the agent can do with it.

Prompt-injection & untrusted-content defense

• Treat fetched/MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. content as untrusted data, never as instructions — the model may read it, but capability controls decide what it can act on.
• Least privilege limits the damage — even a successful injection can't rm -rf or exfiltrate if commands are blocklisted, egress is sandboxed, and the run is VM-isolated.
• MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. allowlist shrinks the injection surface — fewer connected servers, fewer paths for hostile content to enter.
• Hooks as a tripwire — scan for secret patterns before commit/egress; gate writes to sensitive paths.
• Human review on merge — for anything regulated, a person signs off; the agent proposes, the human disposes.

A concrete least-privilege pilot config for a SOX repodeny-by-default

SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting. repos govern financial reporting controls — segregation of duties and change-evidence are non-negotiable. The agent can be a force multiplier here, but it starts maximally clamped and earns nothing on day one beyond proposing changes a human reviews.

Maturity path: autonomy is earned

You don't start at Cloud Agents auto-merging in a SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting. repo — you start at 'propose, human disposes' and graduate rungs as evidence accrues: clean review pass rates, no escaped defects, audit trail intact. Box's published numbers (85%+ daily active, 30–50% throughput, +75% usage in six weeks driven by mentorship) came from staged adoption, not a big-bang autonomy switch. Higher autonomy is conditional on evidence + controls — never the start.