What can 1ADK reach inside my systems?

#What 1ADK can reach

Nothing inside your systems. This is an architectural property, not a policy.

The product contains no field for a repository URL, no storage for a deploy key, no SSH client and no outbound connector to a customer environment. There is nothing to misconfigure, because there is nothing configured.

Every exchange is initiated from your side over HTTPS — a person uploading a file, or a coding agent you connected opening a scan and asking 1ADK for the ones waiting on it. 1ADK never initiates a connection towards you, and connecting an agent does not give it anything to initiate one with.

#What 1ADK holds

There is no sixth row. No source code, no configuration values, no database contents, no credentials of yours of any kind — and not the connection key either, which is held as a hash and cannot be read back out.

#The path a package takes

Four gates, and a person standing at the third one.

1. Quarantine on arrival

   The bytes that arrive go somewhere that is not a project store and is not reachable by the rest of the product. Nothing has been parsed.

2. Validation, including a secret sweep

   The file is checked against the package schema, its size limit and the scan job it claims to belong to. Free text is scanned for the shapes credentials take — bearer headers, AWS access keys, private key blocks, Stripe and Slack token prefixes. A package carrying one is refused whole; nothing partial is kept.

   This is a second line of defence. The first is that the instruction forbids values and secrets, and the third is that nothing is written into your project until a person has read what arrived and approved it. None of the three is a proof, and the page does not present them as one.

3. A person decides

   A validated package waits for an explicit approval from somebody on your side. Nothing reaches a project store without it.

4. One writer, verified lock

   An approved package is handed to that project's single writer, which holds a lock it re-verifies as still held, writes in short transactions, and leaves the store untouched if anything fails.

#How projects are kept apart

One project is one logically isolated store. Not one schema in a shared database with a tenant column — a separate store, addressed separately.

The consequence worth stating: there is no query in the product that returns knowledge from two projects at once. A bug that forgets a tenant filter is the classic multi-tenant data leak, and the shape of the storage here does not have that failure mode available to it.

The public website you are reading is a separate application with no platform database credentials, no store paths and no private secrets. It is enforced at runtime rather than trusted: the application removes its own database connections at boot, so accidental data access fails closed instead of quietly connecting somewhere.

#What the boundary does not protect you from

The part of a security page that is worth reading.

1ADK's boundary is real and it is narrow. Here is what sits outside it.

• The coding agent reads your code. Whatever agent runs the instruction sees the repository, and if it is a cloud agent then that vendor's terms apply to what it sees. That is already true of every other task you give that agent — but it is not something 1ADK's boundary covers, which is why this site never promises that nobody else ever sees your source.
• Metadata can be sensitive on its own. A path called app/Services/AcmeBankIntegration.php names a client. A component called LayoffQueue names a plan. The metadata preview exists so you can look at this honestly before deciding.
• A map is a map. The picture 1ADK builds tells a reader where things are and which parts nobody has checked. In the wrong hands that is a useful document. It is protected as such — but it is not harmless-by-nature just because it is not source code.
• Whoever can sign into your account can read it. Account security is shared: a compromised password on your side is a compromise of the picture, and 1ADK does not offer customer MFA yet to reduce that.
• 1ADK does not test your software for vulnerabilities. It is not a scanner. A clean map is not a statement that your system is safe.

#Accounts and access

• Customer sign-in is email and password, with a reset flow. Multi-factor authentication for customer accounts does not exist yet.
• Internal administrator accounts are created from the command line — never self-service — and require a second factor. Administrator recovery is also a console operation; there is no reset link for it.
• The customer application and the internal console are one codebase and two security zones: separate host, separate route group, separate session cookie, separate headers.
• Unknown authorization is denied rather than allowed. Where the product cannot establish that you may see something, it does not show it.

#How the system behaves when something breaks

A rule worth publishing, because it decides what happens on the worst day.

Availability fails soft. Security and integrity fail closed.

A region that cannot be read reports its own condition in place instead of blanking the page. A write whose integrity cannot be verified is not committed. When the write queue is unavailable, writes wait — the product never falls back to writing directly, because a fallback that skips the lock is how two writers corrupt one store.

In plain terms If part of the product cannot load, the page says which part and keeps working. If the product cannot establish that something is authorised or that data is intact, it refuses.

The same rule shows up in the knowledge itself: an unverified claim is marked as unverified rather than presented as fact, and a component that could not be confirmed as removed is not reported as removed.

#What 1ADK does not claim

These are gaps rather than positions. They are listed because a security page that only lists strengths is the least informative kind, and because a buyer who discovers one of them after signing has a fair complaint.

#Reporting a vulnerability

Email security@1adk.com with enough detail to reproduce the issue. A person reads it and replies.

There is no bounty programme, and there is no legal threat either: reporting a real flaw in good faith is a favour, and it is treated as one. Please do not test against other people's projects, and please do not publish a working exploit before there has been a chance to fix it.

You are reporting to a named company, not to an anonymous address: FinMV SIA, registration number 40203378371, registered in Latvia on 8 February 2022.

There is no telephone line and no postal address. The mailbox above is the whole list, and it is read by a person.