Security
What agents touch, and what stays with you.
We will not wave badges we do not hold. Here is how the work is shaped, and the questions we expect you to ask before you grant access.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Your merge stays the gate.
- 2
Work arrives by pull request.
- 3
A person reviews on our side too.
- 4
Ask us anything in writing.
The safety comes from the process.
These are true of every request.
- 1
Agents need to read your code
To follow your patterns, agents and our team need access to the repository they work on. Give only the repositories in scope.
- 2
Nothing reaches production by itself
Work arrives as a pull request. Your engineers review it and decide what merges. Deployment stays yours unless you choose to hand it to us.
- 3
Your secrets stay yours
Do not send production credentials in a request. If a task truly needs one, talk to your account manager first and agree how it will be handled.
Good questions before you grant access.
Ask in writing and get the answer in writing, before you pay.
- Which AI model providers will see our code?
- Who on your team can access our repository?
- What is the narrowest access you need?
- How is access removed when we stop?
- Do you hold any security certifications today?
- Will you sign our DPA or NDA?
See what an agent can touch before anyone grants access
- Before you give anyone access to your code, you want to know exactly what they will see, what they can change and what happens next. That is a fair question, and it deserves a plain answer before you pay.
- Here is the short version. Agents need to read the repositories in scope so they can follow your patterns. Work never reaches production by itself. It arrives as a pull request, your engineers review it, and your team decides what merges. Deployment stays with you unless you choose to hand it to us.
- Once you see that path, the question changes. You stop asking whether anything could go wrong and start asking which controls you want to set on your side. Most teams already know how to set those controls. They use the same access rules they apply to any contractor or new hire.
- This page walks through what agents touch, the gates that stand between the work and your product, and the questions to put in writing before you grant access. You leave with a list you can act on, not just a feeling that it is probably fine.
Your merge stays the gate, and your secrets stay yours
Two rules shape the whole relationship.
First, your merge is the gate. Nothing lands in your product unless your engineers approve it. Second, your secrets are yours. Do not send production credentials unless we have agreed how they will be handled.
The first rule means a bad change has to pass your review before it can do any harm.
An unmerged pull request changes nothing in your product. Your existing branch protection and review habits do the protecting, the same way they do for your own engineers' work. You do not have to invent a new control for agent output.
The second rule takes some discipline on your side.
Keep production keys, database dumps and customer records out of requests and out of the repositories in scope. Use made-up test data instead. If a task truly needs a real secret, talk to your account manager first, and agree how it will be handled before anyone touches it.
The benefit is calm.
Your security team does not have to take a promise on trust. It can read the rules, set the access it wants, and watch every change arrive through the same door it already guards. If a rule is not working for you, you can tighten it the same day.
There is also a practical reason to keep the gate where it is.
Your engineers already know how to review a pull request for risk. They know which files are sensitive, which modules need a second reader and which changes need a careful test run. Keeping the merge in their hands means that knowledge keeps doing its job.
Work arrives as a pull request on your repository.
Your engineers review each change and decide what merges.
Deployment stays with you unless you choose to hand it to us.
Production credentials do not belong in a request.
A person checks the feature against your criteria before your team sees it.
Controls that come with every request
- Some protections are not extras. They are part of how each request runs. Here is what you can count on, and what you can check for each one.
- Access is the first control to set. Give read and write access only to the repositories the work needs, and nothing wider. If your environment supports it, use your own access groups, so you can change or remove access in one place. Ask us to name the people on our side who will work on your repository, so you know exactly who holds the access you granted.
- The PRD is the second control. It lists the scope, the stories and the criteria in plain words. You read it and approve it, and nothing is built until you do. If a criterion is vague, change it before you approve. A vague criterion is a risk you accept without noticing, and it is cheap to fix at this stage.
- The third control is the pull request itself. Your reviewers read the diff, run the tests and apply your usual security judgment. Ask us what automated checks run on each diff. Do not assume a check exists because we mention tests. Tests check behavior. They do not replace a security review, and we will not pretend they do.
- The fourth control is a person. Manual QA happens before the pull request is raised. That person checks the feature against the criteria you approved. It does not replace your review, but it catches the odd error message and the broken flow that an automated test may miss.
- The fifth control is your own history. Every change sits in your commit history, tied to a branch and a pull request. If something needs to be traced later, the trail is in your repository as ordinary pull requests.
- This website is hosted on Cloudflare, which processes technical data such as IP addresses to serve and protect it. The privacy page covers that in more detail.
- The last control is the one you hold alone. You decide when code reaches users. Releases stay in your hands unless you choose to hand them to us. That split is intentional. The people who carry the pager should be the people who decide the release.
You give access only to the repositories in scope.
Written PRD approval before any building starts.
Acceptance criteria that say what done looks like.
Tests in the same pull request, run before it is raised.
A person clicks through the feature before your team sees it.
Deployment held by your team unless you hand it over.
Your security team can say yes with a clear reason
Security reviews go better when the people reviewing know what they are approving.
Vague promises make them nervous. Specific answers, in writing, let them decide quickly and with confidence.
We do not have customer quotes to show you, and we will not invent a badge or a certificate. We do not list certifications on this site, so do not assume we hold any. What we can give you is the shape of the work, written down, with every gate named.
Think about what happens on a normal request.
The PRD aims to arrive the same business day you ask. You see the scope and the cost. You approve it or change it. A pull request appears in your repository, and your engineers review it. At each step, someone on your side has a say. That is the reason your security team can say yes.
The reassurance is practical.
If you are the person who has to sign off, you can read every control on this page, test the setup on a small request, and stop if something looks wrong. You do not have to bet the account on trust.
Ask for the control list in writing before you prepay.
Set it beside your own security policy, and let your security lead mark any gap. A gap named early is much cheaper to close than one found after the first merge, and it is far easier to talk about before money changes hands.
Some teams want to run a short check before they widen access.
That is a sensible instinct. Start with a single request, a single repository and a single reviewer. Read the PRD, read the pull request and see how the tests behave. If the first request meets your bar, widen the scope with a clear reason on paper.
How access differs across hiring, agencies and coding tools
- Every route to more engineering work puts someone's hands on your code. The question is whose rules apply, and how easily you can see and change them.
- Hiring puts people on your payroll and under your policies. Their access follows your joiner and leaver process, and you control it through your own tools. The risks are familiar, and so are the controls. The downside is the time it takes to get someone working well.
- Agencies vary widely. Some work in your repository under your rules. Others work in their own environment and hand over at the end. The security story depends on the contract and the handover. Ask where the work happens, who can access it and how access ends, and get the answers in writing.
- Coding tools run where your engineers run them. The access rules are the ones your team already lives with. The catch is that the person driving the tool holds a lot of control, often with little second review. The risk sits with whoever uses the tool each day, and it grows with how much they trust its output.
- Our route puts the review gate in the pull request. Access is limited to the repositories in scope. Work reaches your product only after your engineers approve it. The trade-off is that some of the work happens on our side, so the questions about access and model providers matter more, and we answer them in writing.
- A simple test helps here. Ask each option who can read your code, who can change it, and who can say no before it ships. Hiring answers all three inside your company. Agencies answer them in the contract. Coding tools answer them in your engineers' daily habits. Our route answers them in the access settings, the PRD and the pull request.
- Pick the route that fits your risk. If you need full control of every step, hire. If you have spare engineers who enjoy driving agents, a coding tool may fit. If the backlog is the problem and you can review pull requests, our route fits, once the access questions are settled to your satisfaction.
Hiring:
your policies, your tools, a slower start.
Agencies:
depends on the contract and where the work happens.
Coding tools:
your environment, but the driver holds broad control.
AgentCTO:
scoped access, a pull request gate, and your team approves every merge.
Hard security questions, answered as far as we can today
Security questions deserve direct answers. Some depend on details we agree with you in writing. Where a question is still open, we say so, instead of guessing.
If an answer is still unclear, pause. A clear answer in writing is worth more than a fast start. The questions on this page are the ones we expect you to ask, so ask them early and ask them all.
Which AI model providers will see our code?
Ask us this in writing, and ask for the current list in writing too. The privacy page says to ask us for the current list. Do not grant repository access until you have the answer you need.
Will you sign our data processing agreement or NDA?
Send us your template, or ask what we will sign. We settle those terms with you in writing before work begins. Do not assume a signature until it is confirmed on paper.
What about personal data in our repository?
Keep real customer data out of the repositories in scope, including fixtures, seed files and logs. Use made-up test data. The data processing page explains how to start that conversation with us.
Could our code be used to train models?
This is a fair question, and it belongs in the written list you ask for before you pay. Ask it for every provider that sees your work, and read the answers before you grant access.
What if an agent writes insecure code?
Treat it like any other change. It must pass the tests in the pull request and your review. Ask us what checks run on the diff, and add your own scanners if your policy needs them. Passing tests are not a security review.
What if we revoke access later?
Ask how access is removed when you stop, and get the answer in writing before you start. You should be able to remove our access in your own tools, quickly and without asking us first.
Do you hold certifications?
We will not wave badges we do not hold. This site lists none, so ask us directly, and expect a written answer rather than a logo.
What if someone on our side needs production access to fix something?
Do not give it. Production changes belong in your own release process. If a task needs production help, talk to your account manager first, so the scope and the handling are agreed before anyone touches it.
What if the code we ask for touches payments, health or legal data?
Tell us at the start. Some of those areas need extra review on your side, and the scope may need to be narrower. We would rather hear it before the PRD than after the first merge.
Example: one security fix moving through every gate
This is an example, not a description of your code. Say your team wants login attempts limited, so that repeated wrong passwords slow down an attacker. The request is one story, and it changes how the login endpoint responds after repeated failures.
The PRD lists the story and its criteria.
Your security lead reads them and asks for one change: the criteria must say what the user sees after the limit is hit, and that the limit does not lock out the real account owner forever. You approve the revised wording. Nothing is built before that.
The pull request arrives with tests for the lockout.
A person then clicks through the failed-login flow against the approved criteria. Your engineers review the code and decide whether it merges. Your team decides what merges, so the limit only goes live once your team merges it.
What to look for in a PRD when access or data is involved
- Read the stories with one question in mind: what can this change see or do that it could not before? Name each data field the story reads or writes, and each role that gains or loses an action. If the PRD is silent on either point, ask before you approve.
- Give extra care to exports, file uploads, admin screens and anything that sends email on your behalf. Those features tend to carry data out of the product, so their criteria should say who can trigger them and what gets recorded.
Writing a security criterion someone can check
A security criterion is only useful if a person can test it. Replace 'the export is secure' with a line a reviewer can run: a user without the admin role gets an error when they request the export, and no file is produced.
Example of a second criterion:
an expired session cannot download a report. Each criterion like this gives your reviewer and our team the same test, so nobody argues about what done means.
What a reviewer should check on the pull request itself
- Start with the files that touch authentication, permissions, data access and outbound requests. Read those lines before the rest of the diff. Then confirm the tests cover the failure paths, not only the success path, because that is where permission bugs usually hide.
- Check that the change reuses the existing permission helpers rather than a new one written for this story. A second permission system in the same codebase is a risk your next reviewer will inherit, so ask for it to be removed before merge.
- Ask for the reviewer's notes to stay with the pull request. A note on each permission decision helps the next person see why the code is the way it is.
How prepaid stories and security work fit together
Security work is still counted in stories. A fix such as the login limit is one story, and it uses $5 of the prepaid balance only when its pull request meets the criteria you approved. The price is the same for every completed story, with no separate security line.
Do not treat security as a story you can skip to save money.
If a check is required by your policy, it belongs in the criteria, and the criteria belong in the PRD you approve. A check missing after the merge costs you a rework conversation, and rework is a question to settle in writing before you prepay.
Why trust an outside team with our code?
- That is a fair question, and the honest answer is that you should not trust us on reputation alone. This site lists no certifications. Judge the arrangement by its controls, which you can read, test and tighten on your side.
- Your access is the strongest lever you hold. You can narrow it to one repository, or remove it in your own tools. A vendor that resists those steps is telling you something important.
Will the agents see our production data?
Our advice is to keep real customer data out of the requests and the repositories in scope, and to use made-up data in fixtures and seed files. If a task seems to need real data, raise it with your account manager before the PRD is approved.
Say so plainly in the first email if your repositories hold customer records in any form, including logs. Ask for the answer in writing, because a quick verbal reply does not settle it.
What this page cannot settle for you
This page explains the shape of the work. It does not replace your security review, your penetration testing or your policy. Those belong to your team, and they should run on the pull requests the same way they run on your own engineers' work.
Agents make mistakes, and so do people.
A generated change can look reasonable and still miss a permission check. That is why each pull request needs a reviewer who reads the security-relevant lines, not only a green test run.
Some gaps will be ours to close and some will be yours.
Ours include the manual check a person runs before a pull request is raised. Yours include the branch rules, the scanners your policy requires and the decision to release. Name the split in writing before the first request.
Who this security route is not for
- If your policy forbids any outside party from reading source code, this route is not the right fit. Say so in your first email. A clear no is more useful to your security lead than a long negotiation.
- The same is true if you need an environment we cannot work in, or a review standard we have not agreed to. Those are gaps to settle in writing first. If they stay open, pick a different route, such as hiring, for that part of the work.
What a security reviewer can ask for before the first request
Before any request starts, a security lead can ask for a short list of rules. Keep the list to what your policy truly needs. A long list no one reads does more harm than a short one everyone follows.
Typical items on such a list are the repositories in scope, the branches allowed to merge, and who may approve a PRD that touches access rules. Write them down in the first email.
Reading a failing test as a security signal
- A failing test on a permission check is not noise. It may mean the change grants more access than the criteria allowed. Treat it as a stop sign until a person has read the diff and explained the failure.
- Do not ask for the test to be removed or loosened just to get a green result. Ask for the code to match the criterion instead.
A worked example of a question a PRD cannot settle
Example: your policy asks for logs to be kept for a fixed number of days. That is a question about your own infrastructure, not a feature story. Settle the retention rule in your own systems first, then write a story only if the product itself must change.
How a reviewer records a security decision
When a reviewer accepts a risk, write down what was accepted, by whom and why. Put that note with the pull request. The next person to touch the code can then see the decision rather than guess at it.
Set the access rules first, then send the first request
- Your access rules are the first thing to settle, not the last. Decide which repository is in scope, who on your team reviews, and who can approve PRDs. Then write those answers down where your security lead can read them.
- Send us your first request with the email button on this page. Include the repository scope and any questions from this page you still need answered. We will answer them in writing before any work begins.
- When the first pull request arrives, check it the way you would check any contractor's work. Read the PRD, run the tests, read the diff and decide. Your merge is the gate, and it stays that way for every request after the first one too.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1Who owns the code?
You do. Work arrives as a pull request on your own infrastructure. Your repository, your stack, your review process. To do the work, our agents and team read your repository under the access you agree, and AI model providers may process it. See the security page for details.
2Is this right for us?
It fits if you have a repo, a backlog, and someone who can review pull requests. It does not fit if nobody on your side can review code, because your team makes the final call on every merge.
3What if I need help along the way?
You get a named account manager. That is a real person who tracks every request through to the merge, at zero extra cost. Founders are one email away too.
Send the feature your roadmap has carried for a quarter.
We open the PRD the same business day. Three business days after you approve it, a pull request is in your repo. Judge us on the merge.
Minimum 100 user stories a month, $500 prepaid. No mail app? Write to udit@tinycheque.com.