NDAs for Developers Before Code Access (Practical Guide)

Not legal advice. This is a practical guide from a software team's point of view. NDA enforceability depends on jurisdiction and the specific facts. Have a lawyer draft or review your agreements.

Short answer: Get the NDA signed before the developer receives any code, credentials or detailed specs, not on their first day of work. Make sure it covers source code explicitly, says what they may and may not do with AI tools, and pairs with an IP assignment. Then make access depend on the signature, so nobody gets a clone link before the paperwork is done, and keep a record of exactly what they signed.

Why the timing matters

An NDA mostly protects information disclosed after it's signed. The common failure isn't a weak clause; it's the order of operations: someone is added to the GitHub organization on Monday so they can "get set up", and the agreement arrives on Wednesday. By then they have a full clone.

Two rules avoid this:

No code before signature. That includes the repository, but also architecture docs, database schemas and API specs.
Least access after signature. An NDA is legal recourse after a breach, not a technical control. It works best when there's less to breach. See how to give contractors access to part of a GitHub repo.

It's also normal for freelancers to push back on signing an NDA for an introductory call. Asking for one before you share real details is reasonable; asking for one before you've said anything specific often isn't.

What a developer NDA should cover

This is a checklist of topics to raise with your lawyer, not template language.

Definition of confidential information

Name software explicitly. Generic "business information" definitions may not obviously cover source code. Typical inclusions: source and object code, scripts and configuration, database schemas, API specifications, architecture documents, credentials, and non-public product plans.

Permitted use

Limit use to performing the engagement. Spell out that they may not reuse code, algorithms or designs for other clients or their own products.

AI tools

This is the clause most older templates don't have. Decide your position and write it down:

Which AI coding tools are allowed on your code, and under what account types (for example, only business plans with data-retention terms you've reviewed).
Whether code may be pasted into chat tools, uploaded, or indexed by third-party services.
Whether agents may connect to external MCP servers or other tools while working on your repository.

If you don't address it, you and the developer may have different assumptions about whether sending your code to a model provider is a "disclosure".

Return and destruction

What happens at the end of the engagement: delete local clones, revoke tokens, confirm in writing. Be realistic: you can't verify deletion, which is another reason to limit what was cloned.

Term and survival

Confidentiality obligations usually survive the end of the engagement. Trade secrets may need protection for as long as they remain secret.

IP assignment (separate, but always paired)

An NDA keeps information confidential. It doesn't by itself make the code a contractor writes yours. That's an IP assignment or work-for-hire clause, usually in the contractor agreement. Make sure you have both.

One-way or mutual

When you hire a contractor, you're the one disclosing, so a one-way NDA is typical. Use a mutual one when both sides share confidential material, such as an integration partnership.

Making signing a gate, not a reminder

The process breaks when signing and access are handled by different people or tools. Common setups:

E-signature tool + manual access. HR or a founder sends the NDA through an e-signature service, then someone adds the developer to GitHub after checking. Works if the "after checking" step never gets skipped.
Access request ticket. GitHub access is provisioned through a ticket that requires the signed document as an attachment.
Signing built into the invitation. The invitation link itself requires the signature before any repository access is granted.

Whatever you use, keep a record of: who signed, which exact version of the document, when, and their typed name or signature. If the document changes, you want to know who signed which version.

How Gitfence handles it

Gitfence invitations can require one or more documents (an NDA, contractor terms, an acceptable-use policy) before any code is available. You upload a PDF or write the document in Markdown, then require it for a repository, for a group, or for a single invitation.

What the person sees: they open the invitation link, use Sign in with GitHub, read the document, type their full name and sign, then accept. Until every required document is signed, they get no code. That applies to git as well as the MCP server for their AI agents:

$ git clone https://gitfence.dev/acme/app.git
fatal: remote error: Gitfence: sign NDA for acme/app first: https://gitfence.dev/documents?repo=acme%2Fapp

Agent tokens can never sign or accept invitations; a person has to.

What's recorded with each signature:

The person's account, the document and its version
The SHA-256 hash of the exact content shown (the Markdown text or the PDF bytes)
The typed full name
The time, IP address and user agent

You can download a signature certificate with these details. Other options:

Approval. A document can require an admin to approve each signature before access opens.
New versions. When you update a document you choose whether existing signers stay signed or must sign again.
Access end dates. An invitation can carry a date when access ends, enforced on every access check.
Least access. The same invitation sets what they can see: per folder or file, No access, Types only, Can read or Can edit, with per-person exceptions.

An audit trail records invitations created, accepted, revoked and expired, documents required and signed, and approvals.

Limits

Gitfence records signatures; it doesn't give legal advice or decide whether your NDA is enforceable. The e-signature rules that apply to you depend on your jurisdiction.
It only gates access through Gitfence. If someone also has direct GitHub access to the repository, that access isn't gated.
Like any control, it protects from now on. It can't recall what someone saw before signing.

For employees, the same gate fits into onboarding new developers without full codebase access. See also Gitfence for contractors and Gitfence for onboarding.

A practical sequence

Send the NDA (and contractor agreement with IP assignment) before sharing anything specific.
Grant access only after signature, scoped to what the work needs.
Keep signatures tied to the document version and content.
Review access at milestones; remove what's no longer needed.
At the end: revoke access, request deletion confirmation, and keep the records.

FAQ

Should I ask a freelance developer to sign an NDA before the first call?

Usually not. Many developers decline NDAs for introductory conversations, and you rarely need to share anything confidential at that stage. Ask before you share code, specs or architecture.

Does an NDA cover code the contractor writes for me?

Not by itself. Ownership of new work is usually handled by an IP assignment or work-for-hire clause. Have your lawyer make sure both are in place.

Can an NDA stop a developer from using AI tools on my code?

It can set rules for it, and you should say explicitly which tools and account types are allowed. Enforcement is still after the fact, so pair it with limiting what code they have.

Is a typed name a valid signature?

In many jurisdictions electronic signatures, including typed names, can be valid, but requirements vary. Ask your lawyer what's appropriate for your agreements and where your contractors are.

What should I do when a contractor's engagement ends?

Revoke their repository and token access, ask them to delete local copies and confirm in writing, and keep the signed agreement and access records.