Security and governance

AI becomes more useful when it can access business context and take action. Those same capabilities create responsibility.

Paraline’s security model begins with a simple rule: every person, AI agent, workflow, and integration is an identifiable participant with limited authority.

That means the system should know not only who connected, but also which workspace they may enter, which records they may see, which actions they may request, which decisions need approval, and how the result will be recorded.

Identity comes first

Before the system can decide whether an action is allowed, it needs to know who or what is acting.

A human user may sign in through the company’s identity provider. An integration may use a service identity. An AI agent can operate through a defined agent identity owned by a workspace. A workflow also needs an explicit owner and scope.

The system should preserve the chain of responsibility. If a manager asks an agent to update a case through a CRM connection, the history should distinguish:

• the manager who initiated the work;
• the agent that proposed the update;
• the runtime action that validated it;
• and the connection that executed it.

Recording only the final technical credential would hide how the decision was made.

A role does not grant everything

A single label such as “operator” or “agent” is rarely enough. Authority has several dimensions.

Workspace access

Which organization or client environment may the actor enter?

Data access

Which customers, cases, documents, relationships, and fields may the actor read?

Action access

Which business operations may the actor request? Reading a record does not imply permission to change it.

Configuration access

May the actor propose changes to forms, data structure, workflows, roles, or agent configuration?

Publishing authority

Who may make a reviewed change active for the rest of the team?

This separation creates useful combinations. An AI agent can read assigned cases and draft replies without seeing billing details. A consultant can propose a workflow change without being able to publish it. A routine workflow can update internal state while a person retains authority over external or financial action.

Use business actions as security boundaries

Broad “write access” gives the caller too much responsibility. A narrow action can express what the business actually permits.

For example, approve_refund can require:

• a pending refund request;
• a reviewer with the correct role;
• an amount within policy;
• and supporting evidence.

The action can record the decision and pass an approved instruction to the payment system. Directly editing a refund_status field cannot reliably preserve all of those rules.

This approach makes agent access easier to understand. Giving an agent three clear business tools is more legible than granting broad database access and hoping a prompt prevents misuse.

Approval is part of the workflow

Approval should not be a sentence in an AI instruction or a message someone might overlook.

The workflow first creates a structured proposal. Policy determines whether it may proceed, must be rejected, or needs a particular reviewer. The review screen shows the target, proposed effect, supporting evidence, and available decisions.

Approval, rejection, requested revision, delegation, or expiration becomes part of the history. Execution uses the parameters that were actually approved. If the proposal changes materially, it needs a new decision.

The amount of review should reflect risk. Drafting an internal summary may be low consequence. Sending it externally is a separate action. Updating a routine priority is not equivalent to changing a financial account or publishing a company-wide workflow.

History supports everyday accountability

An activity record should help answer practical questions:

History is not only for audits. Operators need it to resolve failures, compare AI behavior, and understand why a result looks different from the source.

Logs can contain sensitive information too. More logging is not always safer. The business needs enough evidence for accountability while applying appropriate access, minimization, and retention.

Workspaces need real data boundaries

Each customer or organization workspace should be isolated through the runtime and its underlying data access—not only through what the interface happens to display.

Every request should resolve the workspace and actor before retrieving records. Database constraints, scoped queries, and authorization checks can provide layers of protection.

If PostgreSQL is used as the persistent data store, transactions and row-level security can contribute to this defense in depth. They do not replace application-level authorization or business action policy.

Security also includes encryption, secret management, backups, retention, regional deployment, access review, and incident response. These controls should be documented according to what is actually implemented rather than inferred from a technology choice.

AI agents need limits in addition to permissions

An agent can repeat permitted actions quickly. It may also change its plan based on tool results.

Useful operating limits include:

• how many records one run may process;
• which tool sequences are allowed;
• time and cost budgets;
• concurrency and rate limits;
• external communication boundaries;
• and conditions that stop or escalate the work.

Stopping an agent should not erase the workflow. The system should preserve what completed, what may have changed externally, and what remains open.

Instructions can remind the AI about these limits, but enforcement belongs in the tools and runtime. A control should remain effective even when the model misunderstands an instruction.

Governance should make adoption easier

Good governance is not simply a list of restrictions. It gives a business the confidence to automate appropriate work.

When data boundaries, approvals, history, and recovery are explicit, the team can give agents useful authority in small, measurable steps. Low-risk actions can become faster while consequential decisions remain under human control.

Claims should match implemented controls

This documentation describes Paraline’s intended security architecture. It does not claim certifications, regulatory compliance, retention guarantees, regional hosting, recovery objectives, or provider protections that have not been implemented and established.

As controls become available, their scope and limitations should be documented precisely. See Capability status for the current boundary.