Four modes
Ask, Auto, Plan, Full. Plan mode is read-only and refuses outright: it hands you the plan and tells you to switch mode if you want it carried out. A mode is a ceiling, not a suggestion.
Security
Permission before power.
An agent that can read your files, run commands on your machine, write to your databases and publish to the internet is only safe if you decide what it touches. Every tool belongs to a permission category; the category — not the tool — decides what is asked of you. Three acts can never be approved in advance, in any mode.
8 categoriesPermission, not trust
3 actsAsked every time, even in Full access
1 signing keyHeld off the public API entirely
What bounds the agentFour things stand between
Four things stand between
a prompt and your data.
None of them is the model's good judgement. A model that decides correctly ninety-nine times out of a hundred is not a permission system.
Eight categories
Reading, writing, running a command, changing a database or bucket, writing a DNS record, sending a message, publishing to the internet, spending credits. Reading never asks. A database or DNS change is asked even in Auto mode.
Three that can never be pre-approved
Sending a message to someone, publishing on the public internet, and spending credits on something other than a model call. Asked every single time, including in Full access — « always allow » does not exist for any of the three, because none of them can be taken back.
A ceiling per answer
Each run carries a credit budget. It stops when it reaches it, rather than letting you discover the cost afterwards — and a tool that spends asks first regardless of what the budget still allows.
How it is builtNine mechanisms,
Nine mechanisms,
and the reason for each.
Written from the code that implements them. Where a measure has a limit, the limit is further down the page rather than left out.
- 01Sessions
- Your API key is exchanged for a short-lived session signed with an elliptic-curve key. The public API holds only the public half: it can verify a session and cannot create one. Compromised, it could not mint itself an identity.
- 02Your credentials
- A connection string or an access key you hand over is encrypted at rest with AES-256-GCM and never leaves the server. The agent is shown collections, tables and prefixes — never your keys. The encryption key is rotated by a script that re-encrypts, not by editing a configuration file.
- 03Outbound requests
- Every URL the server fetches is resolved before the request and refused if it lands on a private, loopback, link-local or reserved address — the cloud metadata endpoint above all, which hands out identity tokens. Non-HTTP schemes are refused, infrastructure ports are blocked, and redirects are followed by hand and re-checked, because a redirect would otherwise walk straight around the check. This matters most on the one tool that follows URLs found in prompt text.
- 04Errors
- An unexpected failure answers with a generic message and a reference; the full detail goes to our log under that same reference. The messages that do reach you — a conversion that failed, a page that would not load — are stripped of database URIs, credentials, recognizable keys, internal addresses, cloud project ids and server paths.
- 05Uploads
- A file name from a request never becomes a path. It is reduced to its last segment, reserved characters are stripped, and the resolved path must still sit inside the upload directory or the write is refused. Belt and braces, because the first version of that check was not enough.
- 06Rate limits
- Counted against the visitor's own address, and a forwarding header is believed only when it arrives from a local relay — configuring the server to trust any client's claim is refused at startup. Before that fix every visitor counted as one address, so twenty bad passwords from anyone locked sign-in for everyone.
- 07Deploys
- Environment files, Git directories and dependency folders never ship, and what was dropped is handed back with a reason. A path cannot leave the root. An application's server code is pulled out of the public assets rather than served as one of them — left in, it would have published the app's own source on the app's own site.
- 08Your mail
- Your domain's DKIM private key is encrypted, never leaves the server, and is kept rather than regenerated — a new key invalidates the signatures of mail you already sent. Messages are signed with your domain, not ours. And a sender's HTML is never rendered in the reader: it is stripped to text, because otherwise anyone who writes to you could run script in your session.
- 09Secrets
- No secret has a hardcoded fallback — a missing one stops the start rather than quietly using a default that is the same for every deployment. The public API refuses to start if it is holding a key it has no business holding, which is how the signing key stays where it belongs.
What we do not claimFour things this page
Four things this page
is not telling you.
A security page that only lists strengths is a brochure. These are the limits we know about.
- We hold no certification
- No SOC 2, no ISO 27001, no third-party penetration test report. We are a small company and we are not going to imply otherwise with a badge. What we can offer instead is the mechanism — which is why this page describes how things work rather than who audited them.
- The URL guard resolves, it does not pin
- An address is checked before the request, not held for the duration of it, so a name that answers differently a moment later is not closed off. Shutting that door means pinning the verified address at connection time, which neither the HTTP client nor the browser engine we use exposes simply. We would rather name it here than let the guard read as absolute.
- A shell is not a sandbox
- On your own computer the agent runs with your rights, and the permission prompt is the protection — not a jail. That is precisely why Plan mode is read-only, why a command's approval is remembered as that command and nothing wider, and why the cloud version of this is off rather than on.
- Accepted is not delivered
- Our relay hands a message off as soon as it is queued; what the recipient's provider then does with it is never reported back to us. We tell you which address a message actually left from, and we refuse to send under one you did not choose — but nobody can promise you an inbox.
ReportingFound something?
Found something?
Tell us.
Write to contact@iagenify.com with « Security » at the front of the subject line. Include what you did, what you saw, and the reference if the platform gave you one. If a proof of concept touched data, say whose — including if it was your own.
A person, not a queue. If it is real you will hear what we are doing about it.
There is no payment and we are not going to pretend otherwise. Saying so up front is fairer than letting you find out after the work.
No denial of service, no third party's data, no account that is not yours. Enough to show it, and then stop.
Questions
Security, in detail.
What can the agent do without asking me?
Read, delegate to a subagent, and write its own notes. Everything else depends on the category and the mode: a file write is free in Auto, a database or DNS change is asked even there, and sending, publishing or spending is asked every time whatever the mode says.
Where do the agent's tool results live?
On the device the agent ran on. Our database keeps the step — which tool, a short target, whether it worked, what it cost, how long it took — and never the content of a result. That split is deliberate: the record of what happened is useful to you, and the contents of your files are not ours to hold.
Can the agent reach your internal services?
No. The address check is on by default even in development, and the one place a workflow could have been pointed at a private address has that escape switched off by default — the API is public, and a dev-time convenience there would have let any account read a response from our own network.
What happens if my API key leaks?
Replace it. Keys are stored as a hash, not as the key, so we cannot show you one back — only issue a new one and retire the old. A session derived from a key is short-lived and tied to a session family we can end.
Do you have a bug bounty?
No. Write to us anyway, with « Security » at the front of the subject. We would far rather hear it from you.
Is any of this audited?
Not by a third party. The checks are ours: unit suites with no network, a script that reads each container bound back from inside the container, one that creates a throwaway account and deploys a real site before deleting everything it made, and one that exercises the sign-in path end to end. We would rather tell you whose checks these are than let the word « verified » do the work.