# Agents act. People answer for it

> Agentic by design. 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.

## 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.

- **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.
- **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.
- **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.
- **Links follow the person, too.** A download link handed to an agent stops working if its person is disabled after the link was issued.
- **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.
- **Denials are signals.** Refused agent actions reach the security event stream, so your security team sees an agent pushing at its limits.

## 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.

- **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.
- **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.
- **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.
- **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.
- **Conformance tested.** The server passes the official MCP conformance scenarios that apply to a product server.
- **Your brand on the server.** The server name, its instructions and the confirmation text carry your product name, set in configuration.

[The contract for developers](https://tabellix.dev/developers/)

## 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 |

- **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.
- **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.
- **Never lower than the catalog.** An operation the catalog keeps for people stays with people, whatever a policy says.

## 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.

1. **requests** (agent; a high-risk act)
2. **builds the command** (server; and its summary)
3. **signs in fresh** (person; out of band)
4. **re-checks** (server; both policies)
5. **records** (ledger; who approved what)

- **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.
- **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.
- **Checked again at approval.** The command is authorized again under both policies when the person approves it, not only when the agent asked.
- **Stale means refused.** If anything the command depends on changed in between, the confirmation fails whole. Nothing is half applied.
- **What cannot be shown cannot be approved.** A command too large to display in full gets no approve button.
- **Bounded per session.** The number of pending confirmations per session is capped, so an agent cannot bury its person in requests.

## 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.

- **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.
- **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.
- **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.
- **No reading around a permission.** Search hits require access to the content itself, so search cannot reveal what a permission withholds.

## 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.

- **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.
- **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.

## 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.

- **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.
- **Confirmations on the ledger.** Who approved which command, and when, is recorded beside the action it released.
- **Verifiable like the rest.** Agent entries sit in the same hash-chained ledger with signed checkpoints, and verify offline with everything else.

[Trust and verifiability](https://tabellix.dev/trust/)

## 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.

An illustrative agent session:

- agent (call): create_record  type=deviation  "Temperature excursion, cold room 2"
- policy (allow): within the person's own permissions  ·  trust: high
- ledger (seal): entry 48,213  ·  shard 17  ·  sha256 9f3a…c21e
- agent (call): transition  deviation/DV-0193  event=approve
- policy (deny): regulated preset: approval requires a person's signature
- agent (call): request_confirmation  command sha256 4be1…07aa
- person (sign): QA lead confirmed  ·  fresh sign-in 42 s ago  ·  meaning "approved"
- ledger (seal): entry 48,214  ·  signature bound to version digest
- ledger (proof): checkpoint signed  ·  RFC 3161 timestamp  ·  verifiable offline

## 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 evidence](https://tabellix.dev/trust/)

## FAQ: Questions about agents.

### Can 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.

### Can 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.

### How 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.

### How 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.

### Which 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.

### What 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

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.

Contact form: https://tabellix.dev/contact/

---

This page as HTML: https://tabellix.dev/agents/ · [Site guide for language models](https://tabellix.dev/llms.txt)