keycard-labs - Software Engineer, Security
Requirements
• You've shipped and maintained production code, not only security tooling, and you've found and fixed vulnerabilities in applications or identity systems. • You can read unfamiliar code, build an exploit or reproduction, and ship the fix with a regression test. • You know OAuth 2.0 and 2.1, OIDC, and token exchange (RFC 8693), and can describe failures you've seen, like refresh-token misuse. • You can spot the problem in an IAM policy, a network path, or a cloud audit log, even if you've never run cloud infrastructure. • Good judgment about risk. You can explain an attack path, size it, and agree on a fix with the team. • Agents at work. You use agents for review, triage, or testing, and know how to check their output and limit their access. • STRONG CANDIDATES MAY ALSO HAVE • Experience in identity infrastructure, developer tools, or multi-tenant SaaS. • Experience with DPoP, Cedar, or SPIFFE/SPIRE. • Hands-on AWS security: IAM, SCPs, logging, infrastructure as code. • Securing agents or MCP servers, including tool permissions and sandboxing. • A security tool you built that engineers adopted and that ended a class of bugs. • Public security work: CVEs, bug bounties, write-ups, or OAuth and MCP standards work. • YOUR FIRST 90 DAYS • Month one: map trust boundaries in token exchange and one priority delegation flow, attack them, and compare findings with our risk register. Review the company security setup with platform engineering. • Ship fixes for the findings we agree matter most, each with a CI regression. • Build reusable evidence for customer reviews and a triage process for pentest findings; questionnaires stay with operations. • By day 90: a product and company security roadmap with owners and incident roles, built from the risk register you now own. • WHO WILL LOVE THIS JOB • You'd rather break the product yourself than wait for a customer's red team to. • You'd rather fix a class of bugs once than file the same finding twice.
Responsibilities
• SECURE THE PRODUCT • Threat modeling. Trace how an agent gets access, from token exchange through delegation to the per-tool check at our MCP gateway, then attack it: confused deputies, poisoned tool descriptions, prompt injection, issuer and audience mix-ups, token passthrough. Credentials shouldn't leak between hops, and delegated access should end when it expires or is revoked. • Assume compromise. Even a compromised agent should be stopped from escalating privileges or crossing tenants. Document what it can still do with its access. • Design review. Review designs and code across the token service, Cedar policy engine, MCP gateway, CLI, SDKs, and Console, mostly for who can do what and whether zones stay isolated. • Attack with agents. Run scoped agents against an isolated instance and chase the authorization failures they find. Confirmed failures become CI regressions for token exchange, impersonation, or per-tool policy. Example: a harness that follows a delegated credential end to end and checks it never gains scope or lifetime. • Customer reviews. Be the technical voice when customers' security teams review or pentest us; operations runs the process. • Cloud guardrails. Set the rules for our cloud accounts, pipeline, and customer-hosted cells, down to cell isolation and audited break-glass access. Platform engineering builds them. • Our own credentials. Keep them short-lived and narrow. Design service identity and PKI, sign what we ship to customers, and manage dependency risk. You also use Keycard to scope what our own agents can reach. • Incident response. Investigate vulnerabilities and security events, coordinate fixes, and improve detection. You'll also work out with engineering how on-call works for security.
Apply in one click
Upload My Resume
Drop here or click to browse · Tap to choose · PDF, DOCX, DOC, RTF, TXT