Everything below works today and can be seen on the product screens. It is in the product, not on the roadmap.
All three close the same gap: the product produces the decision and the evidence today, but does not talk to the systems around it. The order is as follows.
Today: The ticket number is typed into the request and its format is validated. Whether the number actually exists is not checked by the product.
Coming: Verifying that the ticket exists and checking its status; a general purpose webhook so any system can be connected; a ready made Jira connector. Your corporate ticketing system stays where it is and the product connects to it.
Today: Sign in through your corporate directory server is supported and a second factor can be enabled.
Coming: Sign in through your corporate identity provider over OIDC and SAML 2.0, and automatic assignment of the product role from your group in that provider. Without the second part the first is only half done: if every new user still needs a role by hand, single sign on gains little.
Today: The audit trail is held signed in the product's own database, has a sealed copy in a separate database and can be exported.
Coming: Streaming audit events to your security event platform in standard formats. The real value is this: we make the decision, and you also see the record on your own platform. You do not have to take our record on trust.
The order of these three is not a preference but a result of observation: the sentence we heard most often in conversations with organisations was "we already have Jira".
We make no promises about these. They enter the queue when an organisation asks for one in a contract or when enough demand appears.
| Item | When it enters the queue |
|---|---|
| Auditor portal: read only access, an evidence verification screen and an audit period package | The auditor role exists in the product; productising it is planned alongside an organisation's audit calendar |
| Recording the origin of a script: a person, an assistant or an automated generator | The rule keeps looking at the text; the origin is kept only for the record and for reporting |
| A database client add-on (SSMS, DBeaver and similar) | When an organisation asks for it in a contract, and for a single client only |
| A fourth database engine | On request. Adding an engine means writing a real grammar parser and is not taken lightly |
The most useful part of a roadmap is where it says why some things are not on it.
Watching live traffic to catch unrecorded work belongs to database activity monitoring products, and those tools do it better than we would. We do not enter that space. We produce the decision and the evidence before execution; your monitor already treats a change with no trace on our side as an exception. The two layers verify each other.
Products that copy an entire database and mask it in bulk are a separate category. We mask the result of a query: the set that leaves production in answer to one request. If you are looking for a masked copy to fill a test environment, we are not the product you want, and we would rather say so up front.
No product can tell you in advance how long a script will hold a lock in production. What we do is different: we derive the risk from the content, prepare the rollback script in advance and record the affected row count after execution.