Keycard Labs | Founding Principal Engineer & Founding Systems Engineer | Full-time | Remote (North or South America)
Keycard is on a mission to redefine machine identity for the AI Era — empowering developers to seamlessly connect people, agents, and services across networks, clouds, and applications. As generative AI and agent-based workflows grow more sophisticated, they demand real-time, adaptable access patterns. Keycard unlocks dynamic, identity-based credentials, ensuring every agent and service operates with precise, contextual permissions—creating a robust foundation for trusted AI systems.
We envision a global identity network, underpinned by open protocols, allowing distributed systems to adapt dynamically, scaling to handle complex AI workloads, and maintain cryptographically verifiable trust relationships. By rethinking secret management and machine identity from first principles, our goal is to delight developers, meet the performance demands of platform engineers, and establish new security primitives for cloud-native architectures — all in an inclusive, collaborative environment focused on consistent, high-quality execution and crafting products that developers love so much they bring them everywhere they go.
I know it's minor, but I love how there is a sticky summary of the application requirements next to the job description, so that I know whether I want to attempt the application earlier on.
Keycard Labs | Founding Principal Engineer | Full-time | Remote
Keycard Labs is fundamentally rethinking infrastructure security, by moving from a world of static secrets and API keys to dynamically-issued, short-lived tokens. In that process, we are delivering an experience developers love, while making it easy to collaborate with teams that operate and secure applications.
This is your chance to build foundational technology that sits at the heart of developer and security workflow. We've all experienced the pain of managing secrets in traditional service-to-service authentication. That pain is only increasing as AI agents integrate with more APIs in dynamic, non-deterministic
ways. We are building the next generation of software to solve those problems.
We are a newly-funded company, co-founded by ex-Snyk and ex-Auth0 engineers with multiple prior startup exits. If you're excited about identity and security, and the opportunity to help shape the future of both the company and the technology, we'd love to hear from you!
There is no website at keycard.sh, your domain was created less than 2 months ago, and Google has nothing on you. Please share more info about your business.
Attestation is an option in the FIDO ecosystem, and it is up to each website whether or not attestation is needed. Attestation is often required in enterprise settings. While consumer adoption of WebAuthn is incredibly low, the introduction of passkeys and multi-device credentials looks poised to change that.
For consumer scenarios, attestation is often not a requirement. In that case, FIDO offers the "none" and "self" attestation modes. None conveys no attestation. Self attestation involves a per-website key pair. Either of these modes are privacy and DIY friendly.
Why are you so negative about this? It works pretty well as an authentication mechanism. Unlike passwords, it can't be leaked or phished.
As for Cloudflare use, it's an experimental hack. An option to avoid filling in a CAPTCHA in case you have a compatible hardware key. You don't have to have one, and you don't have to use it for this if you don't want to.
Can I ask why you chose everyauth over Passport? (I'm the developer of Passport.)
By all accounts, Passport is by far the more popular authentication package (95,000 downloads from npm in the last month vs. 2,100 for everyauth). Furthermore, maintenance of everyauth seems to have come to a halt, leaving outstanding bugs and issues unaddressed. In contrast, Passport has 100% test coverage, and has an API that's been proven stable over ~2 years.
I guess when I decided everyauth over passport about 4 months ago (there was an actual decision process IIRC) it seemed like everauth was more mature, I found more examples and other repos explaining how I could bend it to my needs.
Recently I've come across passport quite often and it appears to be the gold standard nowadays... So yes it's going in at some point in time (this is a minor side project only).
I will happily merge a pull request if you care to go for it - I currently only support facebook and twitter and was working on local user/pass up until an hour ago ... ;)
I lol'd at the title. Just having a Gruntfile is the first smell I notice when looking at a project. Seriously, why take two simple tools and layer a unnecessary "task runner" on top of them?
I generally prefer Make as well and I even made the case for Make when Grunt.js was first announced [1]. That said, I did use Grunt on a recent project and it worked out reasonably well. For myself, I'd prefer to keep using Make, but for many teams, Grunt is a reasonable choice.
I chose Grunt because Make generally requires a lot more background knowledge and ongoing discipline. Most Grunt tasks are configured by relatively constrained JSON data, so it's pretty hard for non-experts to muck it up unless they need to write a custom task. A Makefile would have created much greater education burden for me. That's particularly a concern when the team's Make/shell expert has time-limited involvement with the project.
I find having a "standard" way to run tasks enormously beneficial especially when working with developers cross-platform. Whatever OS you are running, just grunt and all is well. :)
It makes sense when you use it with grunt-contrib-watch. Then you just keep it running as you are developing and listen for the error "ding" after a save.
It seems like just about everyone's written a static site generator. Mine is Kerouac (https://github.com/jaredhanson/kerouac), another Node.js-based generator.
I specifically wanted to apply the middleware concept to generating pages, which turned out to be a decent fit. It ends up being a very similar API to Express, so its instantly familiar to Node.js developers. Check it out.
I like this trend of making ever-more simple static site generators. To promote my own project, check out Kerouac [1] if you prefer your tooling to be in Node.js.
This looks really great! One thing really bothers me however: a dependency on all of Backbone. Pulling in a bunch a view-related code for an ORM has a certain code smell.
Is there any effort to modularize Backbone itself, so that Bookshelf can only depend on the model and collection pieces?
Thanks for checking it out! While the view/history/router related code should be okay just sitting there unused, I agree that does seem like a bit of a code smell. I know Jeremy has been against modularizing Backbone in the past, and there is something to be said about keeping everything packaged nicely together in a single file - though maybe something like this would change his mind.
It's definitely something I'll begin to look into a bit, possibly splitting up the Backbone components into a separate library specifically for Bookshelf, similar to lodash's custom build process. If you have any ideas for a good way to go about this, feel free to open a ticket.
This is fantastic! I'm really excited to see Mozilla improving the login experience for users across the web. It is a problem that is sorely in need of better solutions.
For the Node.js developers in the crowd, I'm happy to see Mozilla is using Passport.js (http://passportjs.org/) (which I'm the developer of) to power the OpenID/OAuth dances when doing identity bridging. You can see it in action at the BigTent repo: https://github.com/mozilla/browserid-bigtent
Passport.js can be used in your own applications to easily perform the server-side part of Persona/BrowserID as well as integrate with or transition from an existing login system.
Keycard is on a mission to redefine machine identity for the AI Era — empowering developers to seamlessly connect people, agents, and services across networks, clouds, and applications. As generative AI and agent-based workflows grow more sophisticated, they demand real-time, adaptable access patterns. Keycard unlocks dynamic, identity-based credentials, ensuring every agent and service operates with precise, contextual permissions—creating a robust foundation for trusted AI systems.
We envision a global identity network, underpinned by open protocols, allowing distributed systems to adapt dynamically, scaling to handle complex AI workloads, and maintain cryptographically verifiable trust relationships. By rethinking secret management and machine identity from first principles, our goal is to delight developers, meet the performance demands of platform engineers, and establish new security primitives for cloud-native architectures — all in an inclusive, collaborative environment focused on consistent, high-quality execution and crafting products that developers love so much they bring them everywhere they go.
Founding Principal Engineer: https://www.keycard.sh/careers/founding-principal-engineer Founding Systems Engineer: https://www.keycard.sh/careers/founding-systems-engineer