Security & Trust
Built to be examined, not taken on trust.
This page states how the Capture Workspace isolates tenants, authenticates people, controls authority, handles untrusted documents and records decisions, with the parameters written down so they can be checked rather than described. It also states what the product does not have. It is written for the person whose job in a procurement is to find the gap.
Tenant isolation
One organisation cannot observe another.
The first question in every procurement diligence pack. It is enforced in the data layer, below the interface, so the answer does not depend on which screen or endpoint is reached.
Scope
An organisation identifier on every record
Every business record carries an organisation identifier from the moment it is created, and every query is scoped through it. There is no unscoped read path and no administrative view that spans customers.
Failure mode
404 not found, not 403 forbidden
A request for another organisation’s record returns not-found. A forbidden response would confirm that the record exists; not-found does not. The existence of another tenant’s data cannot be inferred by probing for it.
Enforcement point
The data layer, not the interface
Isolation is applied where records are read and written, not in the screens that display them. A new endpoint inherits the constraint rather than having to re-implement it correctly.
Inside a tenancy
Restricted pursuits and documents
Tenancy scope is the outer boundary, not the only one. Individual pursuits and documents are restricted further within an organisation through explicit access rows, so a member of a tenancy is not automatically a reader of everything in it.
Authentication
Credentials, second factor, and the life of a session.
The parameters are stated so they can be compared against your own policy rather than accepted on description.
Credential storage
scrypt at N=16384
Passwords are hashed with scrypt at a work factor of 16384. A minimum of twelve characters is enforced and obvious patterns are rejected at the point of choosing. Repeated failures lock the account.
Second factor
TOTP to RFC 6238
Time-based one-time passwords to RFC 6238: HMAC-SHA1, a thirty-second step and a tolerance of ±1 step, implemented on the platform’s own cryptographic primitives. Ten single-use recovery codes are issued, stored hashed, and shown once.
Binding actions
Re-verification at the moment of decision
Where an account has two-factor enabled, it is re-verified at the decision itself and not only at sign-in, so an unattended session cannot carry an approval. Whether two-factor is compulsory for approvers and platform administrators is a deployment setting: an organisation that requires it can enforce it across every account. It is not enforced by default.
Session state
Server-side rows, signed identifier only
A session is a row on the server. The cookie carries only an HMAC-signed session identifier, no user state and no claims, and is set HttpOnly with SameSite=Strict. Revocation is therefore immediate rather than pending an expiry.
Expiry
Twelve hours absolute, sixty minutes idle
Both limits apply and both are configurable per deployment. The absolute limit ends a session regardless of activity; the idle limit ends one that has been left open.
Revocation
Listed, and revocable by the holder
A user can list their own active sessions and revoke any of them. Changing a password revokes every other session immediately. A change of role or account status revokes that member’s sessions immediately, so a withdrawn permission takes effect at once rather than at next sign-in.
Authorisation
Three layers, applied in order.
Ten roles and fifty-five named permissions. Permissions are additive and nothing is implicit. A role holds only what has been granted to it by name.
01 · Role permission
Does this role hold the named permission for this kind of action? The fifty-five permissions are defined individually. There is no wildcard and no inherited super-user.
02 · Record access
Is the record within the user’s tenancy scope, and where a pursuit or a document is restricted, does an explicit access row admit them? Both conditions must hold, not either.
03 · Gate authority
Even holding the permission and the record, only a role listed for that specific gate can decide it, and only within any approval limit recorded against the approver. Holding a permission is not the same as holding authority over a particular decision.
Export-controlled documents are never served to an external partner account. The rule sits below the sharing mechanism rather than beside it, so it holds regardless of what has been shared with that partner, by whom, or in error.
Admission
Registration is reviewed. It is not automatic.
The workspace is linked from this website. Being able to reach the front door is not the same as being able to open it.
Front door
An account is created; it cannot sign in
Registration creates the account and its organisation and queues an access request. Sign-in is refused, with the reason given, until a platform administrator approves it. A defence capture workspace should not hand a tenancy to an anonymous party on the strength of an email address.
Separation of duty
Admitting a tenant is a platform function
The permission to review registrations belongs to the platform administrator alone and is explicitly excluded from customer administrators. An administrator of one customer can never admit another.
Enumeration
No confirmation that an address is known
Registering an address that already exists returns exactly the first-time response. At sign-in, a wrong password against a pending account is indistinguishable from an address that was never registered. The duplicate is recorded as a security event rather than disclosed to whoever submitted it.
Honesty at the boundary
Approval does not claim to have told anyone
Email delivery is not connected in the standard deployment. Approval reports that the requester has not been notified, and the registration form says the same before a password is chosen, rather than implying a message that never leaves the server.
Untrusted content
A tender document is data. It is never an instruction.
A solicitation is written by a third party and then passes through automated analysis. If that document can address the analysis, the analysis is not trustworthy. This is treated as an attack surface rather than a hypothetical one.
Detection
Nine pattern families, plus hidden characters
Every externally sourced document is scanned before it reaches any analysis stage: nine families of instruction-shaped content, together with hidden and zero-width characters used to conceal text from a human reader while leaving it machine-readable.
Handling
Neutralised in place, not silently stripped
Detected instructions are neutralised where they sit and the document is flagged. Nothing is quietly deleted. Silent removal would conceal both the attempt and the fact that the document had been altered before anyone read it.
Escalation
Raised as an alert, not buried in a log
A detection is surfaced as an alert against the document. Someone is told that a supplied document attempted to direct the system, because that attempt is itself information about the source it came from.
Boundary
Content cannot become behaviour
Extracted text is carried as content throughout and is not concatenated into anything that decides what the system does. Requirements are extracted from a document; instructions are not taken from one.
Provenance and audit
Every generated item states where it came from.
A capture file is read later by people who were not there when it was written: a reviewer, an auditor, a customer. What was known, what was assumed and who decided are recorded as data at the time rather than reconstructed afterwards.
Information basis
Six bases, recorded per item
Every generated item records its basis: sourced fact, company-entered, estimate, AI assessment, assumption, or unknown. An estimate is never presented as a fact, and an unknown is recorded as an unknown rather than quietly filled in.
Agent runs
Agent, template version, provider
Every agent run is recorded with the agent that ran, the version of the template it used and the provider that served it. An output can be traced to the exact method that produced it, including long after that method has changed.
Approvals
What the approver actually saw
An approval records the approver, the timestamp, whether two-factor was satisfied, the note, any documented exception, and the immutable payload that was presented at the time. The record shows what was in front of the person, not what the document says today.
Versioning
A prior version is never destroyed
Solicitations, profile items, compliance responses and proposal sections version on change. Earlier versions remain readable, so an amendment or a late correction can be examined directly instead of inferred from the current state.
AI posture
Where your tender text goes.
In the standard deployment, the answer is: nowhere.
In the standard deployment, no content leaves your server. All twelve analysis agents run as deterministic, explainable rule engines on the customer’s own instance. There is no model call, no external inference endpoint and no telemetry carrying document content. Nothing is sent anywhere to be analysed, and nothing is used to train anything.
Optional adapter
Model-assisted drafting is off by default
A model-assisted drafting adapter exists. It is disabled unless it is deliberately enabled in configuration. Enabling it is a decision the customer takes, and one they can reverse.
When it is enabled
Sanitised and fenced before it is sent
With the adapter enabled, tender text passes through the same injection sanitisation and is fenced as content before it leaves the instance. What is sent is scoped to the drafting task; the pipeline itself does not go with it.
Explainability
Weights are configuration you can read
Matching weights are configuration the customer can inspect and change, not hidden logic. A score can be taken apart into the factors that produced it, which is what makes it arguable in a review rather than merely reportable.
Determinism
The same inputs produce the same output
A rule engine run twice over the same inputs returns the same result. An assessment can be reproduced during a review instead of regenerated into something slightly different.
Data handling
Residency, retention, and how a document is served.
Where the data sits, how long it is kept, and what has to be true before a file is handed over.
Residency
A data region recorded per organisation
A data region is recorded against each organisation, with Canadian hosting as the default. Because it is a property of the tenancy rather than a global setting, the answer can be stated for your organisation specifically.
Retention
A retention period per organisation
The retention period is configured per organisation rather than assumed, so it can be aligned to the contractual or regulatory period your organisation is actually bound by.
Document storage
Held outside the web root
Uploaded documents are stored outside the web root. There is no path at which a file can be requested directly, so access never rests on a name being hard to guess.
Document access
Scoped, expiring, single-use tokens
Documents are served only through authenticated tokens scoped to the requesting user and carrying an expiry. A token that has already been used, and a token issued to a different user, are both refused rather than honoured.
Supply chain
Zero runtime dependencies.
The application runs on the language runtime’s own standard library and nothing else. The dependency count is zero, not small.
Dependencies
None at build, none at run
No third-party package is pulled at build time or at run time. There is no lockfile to keep current and no package whose maintainer changes hands without anyone noticing.
What it removes
No transitive tree to audit
With no dependency graph there is no set of indirect packages to review, to monitor for advisories, or to update under time pressure when one is disclosed. The audit surface is the application’s own code.
Build
The container builds with no network access
Because nothing is fetched, the build requires no registry. It is reproducible in an isolated environment, and it still builds when a registry, a package or a maintainer is no longer there.
Why it is deliberate
Unusual, and kept on purpose
This is not the ordinary way to build a web application and it costs effort to hold. It is kept because the alternative, a defence capture tool with several hundred indirect packages inside it, is a harder thing to put in front of a security officer.
The classified-information boundary
What this workspace is not authorised to hold.
Stated plainly and early, because a misunderstanding on this point is not recoverable after the fact.
The Capture Workspace is NOT authorised for government-classified information. It is designed for public, company-confidential, partner-restricted, and controlled or export-sensitive commercial information. Customers must not upload material classified by any government unless the specific deployment environment has been formally accredited for that level, and the standard hosted deployment has not been.
| Information class | Permitted | Handling |
|---|---|---|
| Public | Yes | Openly published material. No restriction beyond ordinary access control. |
| Company confidential | Yes | The default class for pursuit material. Scoped to the tenancy and to the roles granted it. |
| Partner restricted | Yes | Reachable by an external partner account only where that specific record has been shared with it. |
| Controlled or export-sensitive commercial | Yes | Held, with export-control handling applied. Never served to an external partner account regardless of what has been shared. |
| Government-classified: any nation, any level | No | Not permitted. Only a deployment environment formally accredited for that level may hold it, and the standard hosted deployment is not accredited. |
What we do not claim
The gaps, stated before you find them.
A defence buyer discovers all of this in diligence. Saying it first is worth more than being asked about it later.
Certification
No third-party security certification
Iron Shield holds no SOC 2 report and no ISO 27001 certificate for this product today. Any claim otherwise would be false. The controls on this page are described so that they can be tested directly; they are not attested by a third party.
Testing
No independent penetration test yet
Penetration testing by an independent party has not yet been commissioned. Internal testing covers cross-tenant reads and writes, reused and misdirected download tokens, path traversal, executable and macro-enabled uploads and a genuine injection attempt inside a tender document, but internal testing is not an external assessment and is not offered as one.
Single sign-on
Not available
SSO is a later-phase function. It is not implemented, and it is labelled unavailable inside the product rather than described as imminent. Access is by password, with TOTP available on every account.
Notifications do not leave the application
Email delivery is not connected in the standard deployment. Alerts and approval requests appear in the application only. Anything that requires a person to be told out-of-band must be communicated by hand until email is connected.
If a control is not described on this page, assume it is not present. This page is maintained to describe the product as built. Where something is planned it is called planned. If your diligence process requires a control that is not listed here, ask. The answer will be what it is, not what closes the sale.
Diligence questions
The four we are asked first.
Answered at the level of detail a security review needs.
Canadian hosting by default. A data region is recorded against each organisation, so the answer for your tenancy is a stated property of your account rather than a general policy position. Where a deployment carries a specific residency requirement, the region is agreed before the tenancy is created rather than migrated afterwards.
Yes. The application is a single container with no runtime dependencies, and the build requires no registry access, which is what makes a self-hosted or network-isolated deployment practical rather than theoretical. Because the standard deployment already runs every analysis locally, self-hosting changes where the instance sits. It does not change what the instance does.
Your records stay exportable through the term and through the agreed wind-down period, and versioned history exports with them. Data is then held for the retention period configured for your organisation and deleted; that period is yours to set. Nothing is retained for product purposes after an account is closed.
No. In the standard deployment all twelve analysis agents are deterministic rule engines running on your own instance and no content leaves it, so there is nothing held anywhere to train on. Where the optional drafting adapter has been deliberately enabled, sanitised text is sent for that drafting task alone. Iron Shield does not train any model on customer content, and does not sell or share it.
This page describes Iron Shield Capture Workspace as built and deployed. Where the product changes, this page changes with it. Statements about controls that are absent, certification, independent penetration testing, single sign-on and email delivery, are current as at the date of the most recent review and will be updated when that changes, not before.