Source knowledge
Documents, spreadsheets, source systems, expert interviews, policies, precedent and every other input used to understand the institution.
Security and governance
Govern the full path from private financial knowledge to action.
Penomic can connect bankers, investors, risk leaders, actuaries and finance teams to private systems, firm logic, financial models, agents and operational actions. Security cannot stop at encrypted files or model access. It must govern which entities, positions and evidence enter the decision, which calculation runs, who or what may act, where human approval is required and how every output can be reconstructed.
What Penomic protects
Security across the full financial-decision lifecycle.
The protected asset is not only a document. It is the institution’s private meaning, the controls around that meaning and the work produced from it.
Knowledge Architect
The institution-controlled concepts, relationships, definitions, constraints, mappings, provenance, approvals and compiled platform rules.
Agent execution
The context assembled for a task, tools an agent may call, steps it may perform, approvals it requires and evidence it must retain.
Financial outputs and actions
Answers, calculations, financial models, memos, committee packs, workflows, evaluations and downstream actions delivered through Penomic or an approved enterprise interface.
Trust architecture
Meaning moves. Ownership does not.
Penomic is designed so institutional knowledge can become useful across systems without becoming unowned, untraceable or universally accessible.
Data commitments
Customer knowledge serves the customer. Full stop.
Purpose-limited
Customer content is processed to provide the work the customer requests. It is not repurposed for advertising, data brokerage or unrelated product training.
Never used for model training
Customer conversations, files, knowledge-map assets and generated work are not used by Penomic—or permitted to be used by model providers—to train general-purpose models.
Isolated by customer
One institution’s knowledge does not become another institution’s context. Accounts and workspaces remain logically isolated rather than pooled into a shared knowledge base.
Customer-controlled and removable
Customers retain ownership of their inputs and agreed deliverables. Access, deletion, retention and treatment of configured knowledge are governed by the applicable agreement.
Specific retention, deployment and contractual terms are governed by the applicable customer agreement.
Integration credentials
Credentials follow the deployment boundary—not the prompt.
The identity model depends on the connected system and client architecture. Before an API, MCP or A2A interface reaches production, Penomic documents how its credentials are scoped, protected, rotated and revoked.
Provisioned to a boundary
API keys, service identities and agent credentials are issued only for an approved deployment, environment and capability. Production and non-production credentials are separated, with least-privilege scopes agreed during integration design.
Kept out of knowledge content
Secrets are exchanged and stored through approved secret-management channels. They are not embedded in prompts, knowledge-map content, source files or customer-facing financial artifacts.
Managed through their lifecycle
Ownership, issuance, expiry, rotation, revocation, incident response and audit visibility are recorded in the deployment runbook, including whether credentials are client-managed or Penomic-managed.
Providers and data location
Named during design. Bound before production.
The correct provider and region depend on the institution’s control boundary. Penomic does not present one global configuration as if it applied to every deployment.
Depending on the approved architecture, Penomic may use Microsoft Azure and Azure AI services, OpenAI, Anthropic or Groq, together with the identity, storage, monitoring and communication services needed for that deployment. Not every provider is used in every environment.
What the security review records
Provider and subprocessor set, processing regions, content flow, retention, training restrictions, identity, network boundary and change-control obligations. Contractual restrictions govern before a restricted workload moves to another provider or region.
Controls, stated honestlyAvailable Configured with the client In progress
What exists now, what is configured, and what is still being built.
A security page should reduce diligence work, not create it. We separate current controls from deployment decisions and roadmap items so buyers can assess the real posture.
Core data protection
- Encryption in transit and at rest
- Customer-account isolation
- Contractual no-training restrictions
- Team-scoped access and session controls
- Data processing agreement at onboarding
Enterprise deployment controls
- Regional data-handling requirements
- Custom deployment and network boundaries
- Retention and deletion schedules
- Source-system and integration scopes
- Knowledge-map ownership and approval workflow
Assurance roadmap
- SOC 2 Type II readiness and audit program
- SAML-based single sign-on
- Expanded administrative controls
- Formalized customer assurance package
Decision chain of custody01 · Capture 02 · Formalize 03 · Simulate 04 · Decide and act 05 · Record and learn
Follow one institutional event from meaning to action.
The central control question is not merely where a file went. It is whether institutional meaning stayed attributable, reviewable and bounded as it became executable.
Risk, legal and treasury define how counterparty exposure propagates across entities, agreements, collateral and liquidity.
Every definition, rule, relationship, data boundary and decision right is attributable to a source, owner and effective scope.
The response becomes a governed decision graph connected to approved positions, contracts, limits and scenario models.
Meaning, mappings, calculations, constraints, permissions, review state and accountable owners remain attached.
A downgrade event recomputes net exposure, breached limits and capital and liquidity impact at the effective time.
The run receives only approved sources, models and tools; assumptions and scenario versions remain inspectable.
Penomic proposes limit, hedge, funding and escalation actions and assembles the CRO/CFO decision pack.
Agents may recommend or execute only inside assigned authority; required human approvals gate consequential actions.
The institution retains the evidence, actors, approvals, actions and outcome—and updates the operating model when policy changes.
Immutable decision history and managed releases improve the live system without silently rewriting prior decisions.
For security, risk and legal
A review package built around your deployment.
The relevant controls depend on whether Penomic is used directly, embedded by a partner, connected to internal systems or made available to other agents.
Request the security review01Architecture and data flow
We document what enters Penomic, where processing occurs, which providers are involved and how information leaves through approved surfaces.
02Provider and subprocessor controls
No-training and purpose-limitation requirements flow down to providers used to perform the service.
03Identity and access
Current authentication, team access and session controls are documented honestly; enterprise identity requirements are agreed during procurement.
04Integration credentials
API keys, service identities and agent tokens are scoped to the approved deployment; secret exchange, storage, rotation, expiry and revocation are recorded before production access is issued.
05Retention and deletion
Workspace content, temporary processing artifacts, backups and contractual retention requirements are addressed in the applicable deployment plan and agreement.
06Incident and assurance process
Security contacts, review materials and the active assurance roadmap are shared through the enterprise review process.
07Agent and knowledge-map governance
We map who can change institutional meaning, which agents can consume it, what tools they can use and where human approval remains required.
Design the boundary before deployment
Map the state, logic, agents, approvals, and actions your control framework must govern.
Bring the intended mission, architecture, and security requirements. We will distinguish current controls, deployment choices, and any work required before production.
Purpose-Limited · Customer-Isolated · Never Used for Training