Prompt injection
Retrieved or user-supplied content may attempt to override policy, widen tool scope or redirect the task.
Inside PIA
How PIA works.
One relationship. Separate layers. Human authority.
PIA is not one giant prompt wrapped around a language model. The customer experiences one Pia; underneath, identity, memory, specialist capability, compute, privacy, permissions, evidence, safety and recovery are deliberately separated.
Public-safe architectureEvidence-aware statusProtected internals withheld
Architecture at a glance
One Pia on the surface. Separate, governed systems underneath.
A specialist route can add knowledge, tools or structure. It does not create a new personality, new customer identity or new authority.
The model is an engine.PIA is the relationship, cockpit, memory, routing, controls, evidence and recovery architecture around the engine. Relationship identity, memory, authority, permissions, evidence and specialist context are deliberately separated from any one inference model. The engine can change. The relationship and control model should not have to reset. Actual provider substitution still depends on implemented adapters, policy and release configuration.
Threat model
What PIA assumes can go wrong.
Persistent agents have to assume that useful inputs may also be hostile, stale, misleading or simply wrong. Webpages, files, email, model output, provider responses and delegated workers can supply evidence or requests; none is allowed to promote itself into trusted authority merely because it is fluent or arrives through a connected system.
Authority escalation
Familiarity, memory, stronger compute or a connected account can be misread as permission to do more than was authorised.
Boundary failure
Cross-tenant leakage or over-broad disclosure can expose information to the wrong customer, role or provider.
Stale authority
Sessions, workers, permissions or approvals may be revoked, expire or become invalid when task conditions change.
Connector failure
A compromised or misconfigured connector may return unsafe instructions, wrong state or misleading success signals.
Ambiguous effects
A lost provider response can make it unclear whether a message, booking, payment, deletion or other consequence actually occurred.
Duplicate execution
Blind retry after an ambiguous result can create a second consequential effect instead of safely completing the first.
Memory poisoning
Malicious, mistaken or context-dependent material can become a durable preference or fact if memory writes are not governed.
Claims drift
A website or interface can keep describing a capability as live after a dependency is unavailable, limited or retired.
External content, model output and provider output may be useful evidence. None automatically becomes trusted authority.
Three separations worth remembering
Familiarity is useful. It is not authority.
Personality ≠ Identity
Pia can become more concise, casual, formal or culturally appropriate without becoming a different customer identity.
Identity ≠ Authority
Knowing who the customer is does not by itself authorise payment, publication, deletion, permission changes or other consequential action.
Memory ≠ Permission
Remembering “I usually approve these” does not silently become permission for the next consequential action.
Architectural invariants
Engineering constraints intended to survive model changes.
These are falsifiable design rules—not claims of formal verification. The point is to keep privilege expansion explicit rather than allowing it to emerge accidentally from personalisation, memory, compute, provider content or familiarity.
Presentation non-escalation
Changing tone, language, humour, familiarity or cultural delivery must not increase effective action authority.
Memory non-escalation
Retrieved or inferred memory must not create permissions, spending limits, identity claims or security authority.
Compute non-escalation
More capable models, workers, tools or compute must not widen permission or lower the risk class.
External-data non-escalation
Email, webpages, files, provider responses and model output are data; they must not broaden owner authority.
Connection non-equivalence
Technical connection to a provider does not imply permission for every operation that provider exposes.
Evidence-bound completion
A consequential action must not be reported as completed without evidence meeting the relevant result threshold.
Enforced tenant boundaries
Customer and role separation must be enforced by identity, storage and policy controls outside model prose.
Independent hold release
A critical protective hold must not be self-releasing through the same control path that created or reviewed it.
Human recovery independence
Critical recovery must not depend solely on the conversational AI character agreeing to cooperate.
Stable identity, adaptive expression
Pia can adapt without rewriting who she is.
The shared relationship identity remains stable while surface expression can adapt: tone, humour, formality, language, voice, cadence and level of explanation.
A request such as “be more casual” changes delivery. It does not rewrite permissions, security, customer identity, protected governance or recovery authority.
Evidence postureBuilt foundation
Current implementation records evidence shared Pia personality, central text chat and limited state/continuity foundations. Exact release scope still follows current product evidence.
Cultural & relationship intelligence
Culture provides a starting point. The individual person becomes more important.
The Japanese architecture makes the principle especially clear: Pia remains Pia. Language and cultural defaults refine expression; they do not swap in a different personality.
Current situation, relationship state and explicit individual preference progressively refine delivery. That is intended to avoid both generic machine translation and permanent cultural stereotyping.
Same Pia.
Different culturally appropriate expression.
Different culturally appropriate expression.
Memory & continuity
Memory is a purposed state system — not a transcript dump.
PIA separates what is happening now from what should persist. An unfinished project can remain resumable without becoming permanent biography.
Explicit outranks inferred
A direct customer correction should beat a learned preference. Sensitive facts and authority are not supposed to be invented from behavioural inference.
One continuity layer
Specialist contexts query a shared governed continuity layer rather than maintaining contradictory customer identities.
Forgetting has to mean something
Deletion and de-reference are architectural concerns, not merely hiding an item from a screen.
One Pia, specialist depth behind her
Directors are specialist context layers — not a crowd of bots.
Travel, business, language and future specialist roles can contribute domain data, knowledge, workflows, tools and provider connections while Pia remains the speaker and relationship owner.
Routing to a specialist may increase depth. It must not increase permissions, spending authority, safety authority or account authority.
PACE — PIA Adaptive Compute Engine
Match the intelligence to the job.
Ordinary AI systems often ask, “Which model should answer?” PACE asks a broader question: what combination of reasoning, tools, context, workers, priority and time is appropriate for this job?
Complexity, importance, error consequence, quality, urgency, available context and sensible resource expenditure can all matter. The customer should be able to say things like “no hurry”, “keep the cost down”, “do a really good job” or “I need this quickly”.
More compute does not mean more authority.
PACE may change resource choice, reasoning depth, parallel work, time and cost. It does not silently change permission, safety classification or human approval requirements.
Evidence postureArchitecture + foundation evidence
Adaptive-compute architecture is canonical; current production evidence supports foundations and telemetry rather than a blanket claim that every PACE route is fully deployed.
Research, provenance & evidence
PIA should know not only an answer — but the basis for the answer.
The evidence architecture distinguishes sourced fact, inference, estimate, conflict, unknowns and stale/current information. Higher-rigour questions can route into Ask the Boffins rather than forcing every everyday interaction into maximum research mode.
FACTINFERENCEESTIMATECONFLICTUNKNOWNFRESH / STALE
The machinery stays mostly behind the scenes. The trust does not.
Privacy & minimum context
PIA can know the customer without every provider knowing the customer.
External models and services can still be useful. The design goal is selective connection: the durable customer relationship remains under PIA-controlled architecture while an external service receives only what is reasonably necessary for the authorised task.
The customer is the customer — not the advertising inventory.American AI products and sites are designed to remain advertising-free. Provider controls also address unrelated secondary use, advertising-profile creation and model training subject to the exact governing contract and product terms.
Tenant & data compartments
“Please remember not to mix the companies” is not a security control.
PIA Office's engineering baseline uses actual information boundaries: tenant ownership, server-controlled roles, Row Level Security where applicable, and separate retrieval/policy paths for different data classes.
Company A
PublicShared workspaceRole-restrictedOwner privateSecret / audit kept on separate paths≠
Company B
PublicShared workspaceRole-restrictedOwner privateSecret / audit kept on separate pathsThis is a public-safe description of the control model, not an internal schema or security configuration.
Connected actions
Connection does not equal permission.
Technical access, permission, exact action authorisation and proof are separate questions. A connected account is not blanket authority.
Consequence changes the gate
Reading and drafting can be treated differently from publication, deletion, security changes, payment, binding terms or irreversible action. The higher the consequence, the stronger the authority and evidence requirement.
No receipt, no done
Prepared, attempted, submitted/sent, confirmed/completed and unknown/partial are not interchangeable. A provider acknowledgement does not automatically prove the real-world outcome.
UNKNOWN is a valid result.
If the system cannot prove whether an action completed, it should preserve that uncertainty rather than guess success or blindly repeat the action. Where retry could duplicate a message, booking, order, payment, deletion or other consequence, provider state should be reconciled first.
Authorisation follows the effect — not merely the original conversation.
Authority applies to the action actually approved. A material change to recipient, account, amount, currency, price, target, scope, timing, risk or irreversible effect requires the authority decision to be reconsidered.
recipientaccountamountcurrencypricetargetscopetimingriskirreversibility
Protection stack
Protect the customer. Audit the system. Enforce the boundary. Recover deliberately.
These functions solve different problems and are intentionally separated.
Check with Pia
Customer-facing help for suspicious messages, links, invoices, unusual requests, social engineering, risky decisions and recovery. It is assistance, not perfect scam detection.
Independent scrutiny
AUDI examines authority, evidence, contradictions, receipts and control integrity. AUDI is not the daily worker and should not simply execute the action being reviewed.
A prompt is not a security boundary
Protected actions are intended to pass an authority/policy gate outside ordinary conversational generation before execution or hold.
Hold the smallest safe scope
A scoped protected-action hold can stop one risky route while safe chat, explanation, read-only research and planning continue.
Coordinated recovery
Stabilise, preserve evidence, identify scope, contain, recover, verify and learn. The customer remains a primary human authority.
No self-approval loop
The system doing the work should not be the only system deciding whether the work was authorised, completed and safe to release.
Human governance
The AI should not control the only switch that governs the AI.
Surface personality preferences can remain user-configurable while protected governance, operational permissions, oversight and recovery are kept separately governed.
American AI's higher-level human-governance principles are adopted. The later Open Conscience / character programme remains research and should not be presented as a completed security technology.
Evidence postureResearch / future control direction
Open Conscience technical details remain working research. Human stop, oversight and recovery remain part of the protected architecture rather than being delegated to the character itself.
Human authority is not a personality setting.
Capability & claims truth
The website should not be allowed to make the product more capable than the product actually is.
PIA separates document approval from capability approval. The Capability Registry and Claims Registry architecture maps public wording to current evidence, dependencies and limitations.
A brochure is not proof. A mock-up is not proof. Code existing is not automatically proof of customer availability.
From architecture to code
Dated static reference-implementation evidence.
The architecture is not supported only by design documents. A current static inspection of the private reference snapshot, observed 8 October 2026, confirms concrete source structures for shared Pia personality, state/human-presence foundations, Guardian/protection behaviour, typed actions, delegation, capability discovery, integration metadata and server-side connected-action foundations.
Shared Pia personality implementation
State + human-presence foundations
Guardian / protection behaviour
Typed action registry
Delegation structures
Capability discovery
Integration-fabric structures
Connected-action foundations
STATIC SNAPSHOT • 8 OCT 202626 typed action definitions
7LIVE metadata
16CONDITIONAL
3PLANNED
22/26receipt support
R0 2R1 4R2 11R3 5R4 2R5 2
What this proves — and what it does not.
Static inspection shows that these structures and metadata exist in source at the dated snapshot. It does not prove that all 26 actions are publicly available, production-integrated, correctly configured, secure at runtime or reachable by every customer. Conditional and planned actions are not presented as live.
Implementation posture
Built foundation. Governed architecture. Research where it belongs.
The site does not collapse implementation evidence, owner-approved architecture and future research into one claim.
Current records show substantial implemented platform foundations. Exact feature availability remains release-specific.
Canonical or owner-approved architecture with varying implementation depth; not every layer is one fully deployed universal runtime.
Strategically important directions kept clearly separate from current production claims.
How we test it
Architecture should be testable.
A control that cannot be tested is difficult to trust. PIA's separations are intended to support executable tests that try to break the boundary, not merely demonstrate a happy-path conversation.
Prompt injection
Can hostile instructions in email, webpages, files or tool output widen action or disclosure scope?
Authority bypass
Can a model, worker or integration execute an effect without the required effective authority?
Cross-tenant access
Can one synthetic customer retrieve another customer's restricted data?
Stale / revoked execution
Can an expired session, revoked permission or stale worker still act?
Changed approval
If recipient, amount, target or other material conditions change, is prior authority narrowed or invalidated?
Secret exfiltration
Can an external task cause unrelated secrets or customer context to leave the intended boundary?
Ambiguous results
Does a lost provider response become UNKNOWN/PARTIAL rather than optimistic success?
Duplicate retry
Does the system reconcile provider state before repeating a potentially consequential effect?
Memory correction
Does explicit correction or forgetting stop stale information from being used across relevant state?
Claims drift
If a capability, provider or evidence record becomes stale, does public wording qualify or suppress accordingly?
No benchmark score is claimed here.
The academic evaluation programme proposes future use of adversarial-agent and stateful tool-use benchmark families such as AgentDojo, ASB, ToolSandbox and τ-bench, alongside PIA-specific tests. The measures should include unauthorised effects, leakage, duplicate actions, evidence correctness, recovery correctness and utility—not text quality alone.
Future embodiments
One Pia. Many safe embodiments.
The same relationship architecture can extend beyond a browser. Device capability should never create authority.
Future architecture only. A vehicle stack remains responsible for driving safety; a language model is not presented as improvising raw safety-critical control.
Technical transparency without an attack manual
Explain the separation. Protect the exploit detail.
Public technical transparency can describe what the layers do, how authority is separated, why minimum context matters, how receipts work and where humans remain in control.
Credentials, secret locations, privileged routes, unpublished thresholds, exploit logic, containment triggers, adversarial tests and sensitive internal prompt material remain controlled.
Explain publiclyArchitecture boundariesMemory classesMinimum-context principleAuthority modelReceipts and recovery
Keep controlledSecrets and credentialsAttack pathsHidden thresholdsPrivileged admin routesUnpublished tests
Public technical context
Directionally aligned with mature security and AI-governance thinking.
These are contextual references, not certification, endorsement, partnership or a claim of formal compliance.
NIST Zero Trust
Resource-centric access, explicit authentication/authorisation and no implicit trust merely because something is connected.
NIST SP 800-207 →OWASP GenAI
Prompt injection, sensitive-information disclosure and excessive agency reinforce the case for narrow tools and controls outside model prose.
OWASP GenAI →NIST AI RMF
Lifecycle risk management, evaluation, traceability and governance provide useful public comparison points for generative-AI systems.
NIST AI RMF →ISO/IEC 42001
A management-system approach to AI accountability, transparency, risk treatment and continual improvement.
ISO overview →The intelligence is important.
The architecture around the intelligence is the company.Inside PIA
The architecture around the intelligence is the company.Inside PIA