No system runs on typed instructions
Siege never runs a business system on typed instructions to an AI. Asking a model to "build this, and make no mistakes" is how systems fail, and how they are left open to anyone who can type into them.
Siege controls every action instead. Each action, by a person or an agent, is:
defined before it can happen;
permitted to exactly who may take it;
checked before it runs;
traced: recorded with who took it, what it did, when, and on what authority.
People and agents work inside strict, locked-down environments. An agent can do only what it holds keys for, and nothing else.
The application comes first
Agents are never the foundation of a system Siege builds. They come last. The application layer comes first: a working application in which every action is strict, defined by the Ontology and checked before it runs. Only then may an agent work inside it, under the same governance as everyone else.
An agent holds keys. Each key is one action it is granted. Siege gives each agent its keys and the part of the model its task needs, and nothing else. If it reaches for an action it holds no key for, the system refuses it, and the refusal is on the record.
Siege's own software follows the same rules.
The rule
AI works inside the same limits as everyone else in the business. In a client's system it takes two forms, and each has a fixed place.
Form | What it may do | What it may never do |
|---|---|---|
AI features | Draft text for a person: a summary of where a job stands, a checklist from a customer's message, a reply to a customer | Change any data or send a message. A draft is saved only when a person saves it, and sent only when a person sends it. |
The client's agents | Take the specific actions it holds keys for, under the same checks as people | Take any action it holds no key for, go past a business warning, or hold administrator or engineer power |
How the client's agents are held
People and agents take the same actions under the same checks, and an agent's limits are tighter at every step.
Situation | A person | An agent |
|---|---|---|
They hold no key for the action | Refused | Refused |
A business condition is unmet, and the business allows confirming past it | May confirm, and the confirmation is recorded with the unmet condition | Stopped. It can never confirm past a warning. |
Administrator powers | Allowed for the people the client names | Never |
Engineer powers | Held only by Siege's FDE | Never |
Every attempt | Recorded | Recorded, including each refusal |
Each agent can change no more than a fixed number of rows in any one action, has its own rate limit, and can be switched off by an administrator from a screen. Giving an agent another key is a reviewed change, made by a person and recorded.
Text from outside is data
Customers write to the business, and some of what they write will end up in front of an AI. The system treats that text as material to work on, and every AI request marks it as untrusted.
AI features are given no tools and no access to actions. A message that tries to instruct the model can change the wording of a draft, and a person reviews every draft before anything is saved or sent. A link planted in a customer's message is a known risk, and checking for one is part of how the client's staff are trained to review drafts.
Whatever an agent reads, the most it can do is take the actions it holds keys for, inside the business's conditions, and every attempt is on the record.
Every message to a customer is sent by a named person from their own mailbox.
What AI is sent, and on whose account
AI calls go to the client's own account with its AI provider, which is set so the provider does not keep or train on what is sent. Each feature sends only the fields it needs, those fields are listed for the client's review in the data agreement, and fields the client marks as sensitive are never sent. Siege never uses client data to train a model. Each saved or sent text records whether AI drafted it.
Every AI feature has a plain fallback, and an administrator can switch any feature off. If the provider is unreachable, the key is removed or a budget is reached, the screen falls back to its non-AI version and the business keeps running.
Siege's FDE and Siege's own software
Siege’s FDEs are people at Siege. They sign in through Siege’s FDE account, with two-step sign-in, and take actions through the application like any other user. Every sign-in and every change is recorded against that account and visible to the client’s administrators. Changes to the client’s code arrive as pull requests in the client’s repository, and a person reviews and merges each one.
Siege does the engineering itself, with its own software, and that software stays with Siege. It is never installed in a client’s system, it holds no server key and no database login with write access to the client’s production system, and it is not licensed, shown or handed over. It follows the same rules as the systems it builds.
The FDE account is how Siege works on the client’s system under the license. The client’s administrators cannot remove it, and what it may be used for is limited by the agreement. See Ownership and continuity.