Technology
AI Security and Governance
Permissions, data boundaries, audit and behaviour controls for models and agents in production.
The concept
Governance built into the runtime
Controls the agent runtime enforces on every run, for models and agents. The security page covers the platform as a whole, and where the two overlap, it is the one to trust.
Governing AI in a finance or document workflow comes down to four questions a CISO or an auditor will ask. What can each agent see? What can it do? Who changed what it does, and was the change checked? Can you show what it did on a given day? The PTAS AI runtime answers each with a control that runs whether or not anyone remembers it: bounded agents with declared context and tools, permissions granted per tool and per role, rules and models released through approval, and a decision record for every step.
Least privilege applies to agents the way it applies to people. The Invoice Agent can read documents and the vendor master, and it has no tool that writes to the ERP. The Posting Agent can write one kind of document through the integration your IT team approved, and it never sees the invoice image. A language model inside an agent holds no tools of its own, so text inside a document, however it is worded, cannot become an action. People are bounded in the same way: viewing a case, approving a payment, changing a rule and releasing a model version are separate roles.
Change is where governance usually breaks, so a change is controlled the same way whether it touches a rule, a workflow or a model. One role proposes it, another approves it, it takes effect from a stated date, and the previous version is kept. A new model version is evaluated against the one it would replace, on held-back documents of yours, before release, and it can be rolled back. Each decision record names the rule version and model version that produced it, so a question about last March is answered with last March's configuration.
Where it sits
A control at each of the five stages
PTAS AI workflows run as Perception, Intelligence, Orchestration, Action and Verification. Governance has its home in the last stage and a control in every one before it.
In the products
The controls as they appear in DocPro and FinSuite
DocPro governs what is read, kept and passed on. FinSuite governs who and what may change your books.
DocPro
Per-agent permissions
Each DocPro agent can read its own document type and the masters it resolves against. None of them holds a tool that posts, pays or changes a master record.
DocPro
Field-level redaction on export
Identity numbers, dates of birth and any field you classify as sensitive can be masked per destination, so a KYC reviewer and a billing system receive different versions of one record.
DocPro
Retention by your policy
Documents and extracted data are kept for the period your retention policy sets, then removed, with the deletion recorded against the case.
FinSuite
Posting through approved integrations
Only the agents whose job is to post hold the ERP write permission, through the integration method agreed in assessment and the credentials your IT team controls.
FinSuite
Segregation of duties
Whoever codes an invoice cannot approve it, and the approver cannot release the payment. Roles are checked at each step, for people and agents alike.
FinSuite
Permanent human gates
Changes to vendor bank details, new vendors and payments above your authority bands always go to a named person, however confident the agents are.
Worked example
What each agent may touch, and how a model reaches production
The permission map for one payables chain, people included. Then the gate a new version of the invoice reader passed before release. Values are illustrative.
Permissions in one payables chain. Illustrative example
Ask of any AI system what the worst thing each part of it could do is. Here the answer is written down per agent, and it is short.
Declared, then enforced
An agent's tools are listed before it runs. The orchestrator refuses any call outside the list and records the attempt.
People bounded the same way
Correcting a field, approving a payment and changing a rule are three separate permissions.
Readable by your security team
The map is configuration, so it can be reviewed like any access list.
Permissions say what a component may do. They say nothing about whether a new model reads your documents as well as the old one did. That question is answered before release, on your documents, and the answer is kept with the version.
Invoice reader, version 7 to version 8. Illustrative example
A model update changes how your documents are read. It goes through the same kind of control as a change to an approval band.
Tested on your documents
The comparison runs on held-back documents of yours against the version in production.
Approved by someone else
The team that trained the model does not sign off its release.
Reversible
The previous version stays ready, and every field records which version read it.
Limits and controls
What governance cannot promise
Controls reduce what can go wrong and make what did go wrong visible. They do not make a model infallible, and we do not claim they do. A permission map is only as good as its last review, and an agent granted a tool it did not need is a risk until someone notices, so grants are reviewed whenever a workflow changes. An evaluation set represents the documents you had when it was built. A new supplier format can still surprise a released model, which is why scores are watched in production by vendor and by field.
Governance inside the runtime also does not replace your own. Who in your organisation may approve a rule change or a model release is your decision, and the platform enforces whatever you decide. The four controls below are switched on from the first workflow.
Least privilege per agent
Each agent has a declared context and declared tools, each tool with its own permission. Granting a tool and operating an agent are separate roles.
Change approval
Rules, workflows and model versions change through a proposal and an approval by different roles, with an effective date and the previous version kept.
Evaluation before release
A new model version is compared with the current one on held-back documents of yours before it reaches production, and can be rolled back.
Audit trail
Every decision is kept with the values read, the rule and model versions applied and the result confirmed, and stays queryable by the roles allowed to see it.
Deployment models, encryption, access control, retention and incident handling are set out on the security page. The review queues these controls feed are under Human-in-the-Loop.
FAQ
Questions security and risk teams ask about AI
How do you stop an agent from doing something it should not?
By limiting what it can do before it runs. Each agent has a declared context and a declared list of tools, and each tool carries its own permission. The orchestrator executes only calls on that list and records any other attempt. Writing to your ERP is a separate permission held only by the agents whose job is to post, through the integration your IT team approved. Above your thresholds, and for permanent gates such as bank detail changes, a named person decides.
Can a malicious document trick a model into taking an action?
Text inside a document is treated as content to read. The language models that read it hold no tools, so an instruction hidden in an email or a PDF has nothing to act through. What a model returns is checked against a schema, against the source text and against your data before an agent uses it, and actions are taken only by agents with declared tools under your rules. This shuts the route from a document to an action. It does not make a misread impossible, which is why validation and thresholds still apply.
Is PTAS AI certified for ISO 27001?
No. Our security practices are aligned with ISO/IEC 27001 and our delivery practices with ISO 9001, and we design for GDPR readiness. We do not hold certification for any of these, and nothing on this page should be read as saying we do. The controls on this page are ones we can walk your security team through in the deployment model you are considering.
Where do the models run, and does our data leave our environment?
In the deployment you choose: cloud in the region you select, a private cloud account you control, or on-premise where supported, including air-gapped setups for regulated workloads. Documents and extracted data stay inside that boundary. What leaves it, an export to a downstream system for example, can be masked field by field under rules you set.
Keep reading
Where governance connects
Security at PTAS AI
Deployment models, encryption, access control, retention and incident handling.
Read more →Agentic AI Architecture
How each agent is bounded: context, declared tools, rules and a verifier.
Read more →Business Rules
How rule changes are proposed, approved and versioned.
Read more →AI Orchestration
Where each tool call is checked, and refused if it was not declared.
Read more →Next step
Put the controls in front of your security team
Bring one workflow and your review checklist. We will show the permission map, the change history and the decision record for it, in the deployment model you are considering.