One person behind every session
A session belongs to the person who opened it and is tied to their sign-in at the identity provider. Another person cannot pick it up.
[ Agentic by design ]
Agents act. People answer for it.
AI agents can use every staff capability over MCP, under the authority of the person they act for. You decide how far each agent may go, from drafting to signing, and the audit trail always shows who did what.
01 The stance
An agent is never more than its person.
Every agent session belongs to one person and is anchored on that person's own sign-in. The agent gets what the person may do, narrowed by the agent policy you write, and never anything more.
01
02
Two policies, both must agree
The agent policy is applied on top of the person's own policy and can only add restrictions. A missing or failing agent policy denies.
03
The tool list follows the person
Each session sees only the operations its person may use. A restricted person's agent sees exactly what that person sees.
04
Links follow the person, too
A download link handed to an agent stops working if its person is disabled after the link was issued.
05
Hidden stays hidden
An agent cannot learn that a record exists if its person may not see it. Search returns nothing the person could not open.
06
Denials are signals
Refused agent actions reach the security event stream, so your security team sees an agent pushing at its limits.
02 Every capability
The whole product, over MCP.
Agents are not handed a chat window on top of a user interface. They reach every staff capability, 142 operations in the current catalog, through a standard MCP server, and never with more than the people they work for.
01
Task-shaped tools
Typed tools for the everyday work: search, read, history, trace links, draft, capture a record, move it through its lifecycle, complete a task, comment, compare versions.
02
A catalog for the rest
A generated catalog lets an agent find, read and invoke any other operation its person and your policy allow, so an agent is never limited to a fixed tool list.
03
A risk tier per operation
Each operation is a read, a write, a write that waits for a person, or a floor act that only a person may perform. A few, such as approving a confirmation, are never reachable by an agent.
04
A standard server
Streamable HTTP, an OAuth 2.1 resource server with protected resource metadata, read and write scopes with step-up, and token audiences bound to the MCP resource.
05
Conformance tested
The server passes the official MCP conformance scenarios that apply to a product server.
06
Your brand on the server
The server name, its instructions and the confirmation text carry your product name, set in configuration.
03 Allow, confirm, deny
Three answers, per capability.
Your agent policy answers allow, confirm, or deny for each action and for each lifecycle event. A deployer can require a person's confirmation for any write it chooses, and leave the rest to the agent.
| Answer | What the agent experiences | Example |
|---|---|---|
| Allow | The call runs under the person's permissions and is recorded with the agent session. | Search procedures, draft a revision, capture an event record |
| Confirm | The call waits until the person approves the exact command out of band. | Move a deviation to review, update a draft |
| Deny | The call is refused and recorded; the agent is told it may not. | Anything your policy keeps for people only |
01
Written as policy
Agent rules live in the same signed configuration release as every other rule, so they are reviewed as a diff and approved by people other than the author.
02
Decided on the session
Rules can look at the tool, the client, the session, its trust level and the preset, as well as the person, the record and its state.
03
Never lower than the catalog
An operation the catalog keeps for people stays with people, whatever a policy says.
04 Confirmation
The agent asks. The person decides.
High-risk actions are commands computed by the server and confirmed by the person outside the agent's channel. The agent cannot approve its own request.
agentrequestsa high-risk act
serverbuilds the commandand its summary
personsigns in freshout of band
serverre-checksboth policies
ledgerrecordswho approved what
01
The server writes the summary
The person approves a summary built by the server from the exact command, not text the agent chose to show.
02
Only the session's person
Only the person who owns the session can approve, and only with an interactive sign-in inside the signature window.
03
Checked again at approval
The command is authorized again under both policies when the person approves it, not only when the agent asked.
04
Stale means refused
If anything the command depends on changed in between, the confirmation fails whole. Nothing is half applied.
05
What cannot be shown cannot be approved
A command too large to display in full gets no approve button.
06
Bounded per session
The number of pending confirmations per session is capped, so an agent cannot bury its person in requests.
05 Session trust
Trust only goes down.
Prompt injection is handled in the server, not left to the model. When an agent reads text it cannot vouch for, its session loses trust, and lower trust narrows what it may write.
01
Three levels, one direction
A session starts trusted. Reading another party's text or content that has not been scanned lowers its trust, and it never climbs back within the session.
02
Lower trust, fewer writes
Policy narrows what a session may write as its trust drops, so text planted in a document cannot widen what the agent may do.
03
The model does not have to behave
The defense holds even if the model follows the injected text: the server decides what the session may do, not the prompt.
04
No reading around a permission
Search hits require access to the content itself, so search cannot reveal what a permission withholds.
06 Two presets
A regulated floor, or your own line.
The deployer chooses a preset. Under the regulated preset only named people approve and sign. Under the flexible preset you open individual permissions, one switch at a time.
[ Regulated ]
- People approve and sign. Agents draft, capture, comment and move work forward. Signing and approval stay with named people.
- A floor that cannot be loosened. A deployment that turns on any agent switch under the regulated preset is refused when it loads.
- Vendor support stays human. Agents cannot request, approve or use vendor support sessions.
[ Flexible ]
- Signing, by meaning. Allow an agent to sign only with the signature meanings you list, and only while its person's own sign-in is recent enough.
- Switches you set one by one. Signature withdrawal, destruction and disposition approval, sharing, hold release, configuration activation, break-glass, and vendor support requests, approvals and reads.
- Always disclosed. An agent's signature says so on the record, on the signed page and in the audit entry: applied by this agent session, acting for this person.
01
Always a person, in every preset
No agent, under any preset, places a legal hold, proposes a disposition, creates a disclosure, erases a person's data, or changes the configuration on its own word.
02
Sharing is a person's act
Creating, widening or ending a share or an inspector session is a floor act for agents unless the flexible preset opens sharing.
07 On the record
Every call, recorded.
Each tool call and agent action is written to the audit ledger with the person and the agent session behind it, in the same chained history as everything people do.
01
Who, and through what
Every entry names the person and the agent session, so a reviewer can tell what a person did from what an agent did on their behalf.
02
Confirmations on the ledger
Who approved which command, and when, is recorded beside the action it released.
03
Verifiable like the rest
Agent entries sit in the same hash-chained ledger with signed checkpoints, and verify offline with everything else.
08 A session
Drafted by an agent, signed by a person.
An agent drafts a deviation record, is refused the approval under the regulated preset, and asks. The person confirms out of band with a fresh sign-in, and each step lands on the ledger.
- agentcallcreate_record type=deviation "Temperature excursion, cold room 2"
- policyallowwithin the person's own permissions · trust: high
- ledgersealentry 48,213 · shard 17 · sha256 9f3a…c21e
- agentcalltransition deviation/DV-0193 event=approve
- policydenyregulated preset: approval requires a person's signature
- agentcallrequest_confirmation command sha256 4be1…07aa
- personsignQA lead confirmed · fresh sign-in 42 s ago · meaning "approved"
- ledgersealentry 48,214 · signature bound to version digest
- ledgerproofcheckpoint signed · RFC 3161 timestamp · verifiable offline
09 Draft Annex 22
Built for the oversight the draft Annex 22 expects.
The draft EU GMP Annex 22 keeps generative AI out of critical GMP applications and expects qualified people to stay responsible for AI outputs. Tabellix is built for the human oversight the draft Annex 22 expects for generative AI: under the regulated agent preset, agents draft and named people review, approve, and sign, with every agent action recorded in the audit trail. Validating an AI model remains the regulated user's responsibility.
Frameworks and evidence10 FAQ
Questions about agents.
01Can an agent do more than the person it acts for?
No. Each session belongs to one person, and the agent policy is applied on top of that person's own policy and can only remove permissions. A missing or failing agent policy denies.
02Can an agent sign records?
Only under the flexible preset, only with the signature meanings the deployer lists, and only while its person's own sign-in is recent enough. The record, the signed page and the audit entry always say the agent applied it for that person. Under the regulated preset, only named people sign.
03How does a person confirm what an agent wants to do?
The server computes the exact command and a summary of it. The person who owns the session approves it outside the agent's channel, with an interactive sign-in inside the signature window, and the command is authorized again at that moment. The agent cannot approve its own request.
04How does Tabellix defend against prompt injection?
In the server. When a session reads another party's text or unscanned content, its trust drops and stays down, and lower trust narrows what it may write. The defense does not depend on the model ignoring the injected text.
05Which agents and clients can connect?
MCP clients on the current protocol revision or the previous one. The server passes the official conformance scenarios that apply to a product server, and signs a person in with standard OAuth 2.1.
06What do auditors see of agent work?
Every tool call and agent action is in the hash-chained audit ledger with the person and the agent session behind it, and verifies offline with the rest of the history.
[ Contact ]
Put your agents on the record.
Tell us what your agents should do and who answers for it. We'll show you how the presets, the confirmation and the audit trail fit your product.