Cloud, Infra & Least-Privilege Access

Cursor's job description names one project outright: build a least-privilege and JIT system for cloud access that enables engineers without granting unnecessary standing permissions. If you walk into the onsite with a clean design for this, you are answering the question they wrote down.

The threat you are designing against is mundane and constant. An engineer's laptop gets phished, a CI token leaks into a build log, a session cookie is stolen. The damage is bounded by exactly one thing: what that identity could do at the moment of compromise. Standing access is the variable you control.

So the first principle is blunt. Permanent permissions are stored attacker value, sitting there whether anyone uses them or not.

The JIT flow, end to endrequest → approve → time-box → revoke → audit

Just-in-time access means an engineer holds no production privilege by default and elevates only when there is a task and a reason. The grant is scoped, short and self-expiring. Walk the loop in order.

1. 1Request. The engineer asks for a specific role on a specific resource, with a reason and a duration. "Read access to the billing DB for 30 minutes to debug ticket #4821," not "admin on prod."
2. 2Approve. A policy decides: auto-approve low-risk scopes, route high-risk ones to a human or a second approver. The reason and the ticket travel with the request so the approver isn't guessing.
3. 3Time-boxed grant. The system mints a short-lived credential or attaches a role binding with a hard TTL. The clock starts immediately.
4. 4Auto-revoke. On expiry the grant is removed with no human in the loop. Revocation is the default, not a cleanup job someone has to remember.
5. 5Audit. Who requested what, who approved it, what they touched during the window and when it expired - all logged immutably for later review and detection.

The detail that separates a real design from a hand-wave is expiry must not depend on the happy path. If revocation only fires when a tidy background process runs, a crash leaves the grant standing. Time-box at the identity layer (short-lived tokens that simply stop being valid) so that doing nothing is the safe outcome.

Break-glass without permanent backdoorsincidents are when controls get bypassed badly

At 3am during an outage, nobody should be blocked waiting for an approver who is asleep. But the fix for that cannot be a standing god-mode role, because that role is the exact thing you spent the rest of the design eliminating. Break-glass is a controlled escape hatch with its own rules.

Friction is a security risk toodeveloper empathy is in the JD for a reason

A control that is annoying enough gets routed around. Engineers share a long-lived key in Slack because the JIT flow took four minutes and they were in a hurry. Now you have a worse problem than you started with and you can't even see it. The role explicitly asks for frictionless security, so treat speed as a requirement, not a nicety.

Most cloud breaches are not exotic. They are an over-broad role, a public bucket or a metadata endpoint reachable from a request you didn't sanitize. The hardening round tests whether you can name the misconfiguration classes cold and reason about why each one happens.

Identity-based vs resource-based policiestwo sides of the same access decision

An access decision in the cloud is the intersection of two questions: what is this identity allowed to do and what does this resource allow to be done to it. Get the distinction crisp because interviewers probe it.

The misconfiguration classes to name on sightthese recur across every cloud

Network segmentation and service-to-service authshrink what's reachable, kill the long-lived key

Two systemic moves shrink the threat surface more than any single fix. First, minimize internet exposure: private subnets by default, public ingress only through a load balancer or gateway and explicit egress controls so a compromised box can't freely phone home. Second, stop authenticating services with secrets they have to carry.

This is the section closest to the heart of the role. Cursor's agents read, write and execute code, often code the agent itself just generated, sometimes on infrastructure that also touches customer data. Running that code safely is not a checkbox. It is the product's central security problem.

Treat every agent execution as untrusted by default. The prompt could be poisoned, the generated command could be hostile, a tool call could try to read a file it has no business touching. Your job is to give that code somewhere to run where being hostile doesn't matter.

The isolation spectrumstronger isolation costs latency and density

Isolation primitives trade strength against cost. A bare container starts in milliseconds and packs densely; a full VM is far harder to escape but slow and heavy. Know the rungs and what each one actually defends.

Container and Kubernetes hardeningthe floor, even when you also have a stronger boundary

Whatever primitive you choose, the container itself should be locked down. These are cheap, well-understood controls and skipping them is what turns a contained process into a host-level foothold.

• Drop all Linux capabilities, then add back only the few a workload genuinely needs.
• Run as a non-root user with a read-only root filesystem; mount writable scratch only where required.
• Apply a seccomp profile to deny the dangerous syscalls the workload never calls.
• Enforce network policy: default-deny egress, so an escaped process can't reach the metadata endpoint or your internal services.
• Forbid privileged pods, host-path mounts and host networking - these dissolve the boundary entirely.

Assume the sandbox breaksdefense in depth, designed around the blast radius

Every isolation layer has a nonzero chance of being escaped. A mature design accepts that and asks the next question: when this sandbox is breached, what does the attacker reach? The answer should be "almost nothing of value."

Running an agent against real privileged infrathe same instinct, from the operator's chair

The sandbox model isn't only for code Cursor runs at scale. It's also how a security engineer should drive an agent against their own cloud. Travis, who runs this workshop, is GitHub admin and AWS admin. He uses an agent to run elevated AWS commands every day and never hands it his credentials. The trick is a layer of indirection between the agent and the shell.

He keeps a small helper script and tells the agent to call it - he types something like creds prod. The script sets the credential environment variables in the shell. The agent drives that terminal through a tool, but it is not the terminal: it sees terminal output, not the shell's env properties. So the agent can run aws ... | jq against production while the credentials are never exposed to it. Every elevated command surfaces for his approval and he reads each one.

His approval policy is a threat model, not a blanket setting. Reading files runs free almost full-stop. Anything that mutates state or needs network access asks him every single time, because - in his words - his user has more permissions to systems than he's comfortable just handing to the agent. Writing outside the workspace is a non-issue because he works in git workspaces: if the agent changes something, he resets it.

Letting the agent deploy securely, toosecure-by-default IaC, reviewed before the PR opens

The same operator can use an agent to evaluate and stand up a third-party AI tool safely. Asked whether a coworker could run a locally-exposed tool, Travis aimed for safe-but-usable: don't put it on the internet. The tool's own docs recommended a Tailscale connector, so the service stays locked down and still reachable from a phone.

Secrets management is where good intentions go to die in env files. The senior version of this topic is short-lived and centralized: secrets that rotate themselves, keys whose location you can name and an audit trail on every read.

Start from the failure you are preventing. A leaked secret is only dangerous in proportion to its lifetime and reach. Cut both and most leaks become non-events.

The shape of a sane secrets systemcentralize, shorten, rotate, audit

• Centralize in a real secret store (a vault or cloud secrets manager), never in code, images or shared docs.
• Prefer dynamic, short-lived secrets the store mints on demand over static credentials that live forever.
• Rotate on a schedule and on demand and make rotation a non-event the app handles automatically.
• Audit every secret read as a detective control, so an anomalous access pattern is visible.

Encryption: in transit, at rest and where the keys livename the key location or the design is incomplete

Encryption is easy to assert and easy to get wrong. The interviewer is listening for whether you know where the keys actually live, because data encrypted with a key stored next to it isn't meaningfully protected.

CMEK: customer-managed encryption keysCursor offers this to enterprise

Cursor offers customer-managed encryption keys to enterprise customers, so be ready to explain the model. With CMEK, the customer controls the key that encrypts their data, often in their own cloud KMS and grants the provider scoped permission to use it.

The JD lists "logging safeguards against inappropriate data retention" as a responsibility. That phrasing is the tell: at Cursor, retention is a security control, not just an ops setting. Logging both protects you (you can detect and investigate) and endangers you (you can over-retain sensitive code) and a good engineer holds both halves at once.

Log the security events, not the sensitive contentthe line that keeps your audit log from becoming a breach

Logs are where teams accidentally re-collect the data they promised not to keep. The discipline is to log the fact of an action richly while keeping the content out. You want to know that an agent wrote to a file; you do not want the file's contents living in a log nobody is protecting like primary data.

From audit log to detectionlogs nobody reads are just storage cost

An audit log earns its keep when it drives an alert. Detection engineering, in its basic form, is turning the events you log into signals on access that doesn't fit the normal pattern. You don't need a SIEM cathedral to start; you need a few high-signal rules.

• Break-glass used - page immediately, every time, no exceptions.
• A JIT grant for an unusually broad scope or a grant that touches a resource the requester has never touched before.
• A burst of decrypt calls or access from a new geography or a new ASN for a given identity.
• An agent sandbox attempting egress to a blocked destination like the metadata endpoint - that's an escape attempt, treat it as one.

Privacy Mode and tenant isolationthe retention promise has to be enforced, not just stated

Cursor's Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. commits to not retaining or training on customer code when the customer hasn't permitted it. That's a contractual and reputational promise and the engineering job is to make it structurally true rather than a policy people remember to follow.