Security Overview

Security posture as of: August 30, 2026
Last Updated: August 30, 2026

This Security Overview describes the administrative, technical, organizational, and product-design measures used by Ultimate, Inc., which offers the Services under the Attribute brand ("Attribute"), to protect information processed through Attribute's personal services, enterprise and ERP services, organization workspaces, APIs, integrations, document-processing features, AI-assisted functionality, agents, and automation.

This document is informational unless an Order Form, Data Processing Addendum ("DPA"), Security Addendum, or other signed agreement expressly incorporates a particular statement. Customer-specific commitments such as data residency, customer-managed keys, private networking, recovery objectives, audit-retention periods, or service levels apply only when stated in the applicable agreement.

No system can be guaranteed completely secure. Attribute maintains a risk-based security program designed to reduce the likelihood and impact of unauthorized access, use, disclosure, alteration, or loss and to evolve as the platform, data, and threat environment change.

1. Scope

Attribute's security program is designed to protect individual users, enterprise Customers, Authorized Users, administrators, platform operators, service accounts, integrations, background processes, document-processing workloads, AI features, and automated agents. Exact controls may vary by Service, deployment, plan, enabled feature, Customer configuration, and the sensitivity of the information involved.

Attribute separates authentication, authorization, capability control, consent and data use, workflow, safety, and user preferences. An operation may need to satisfy multiple controls before protected information is disclosed or a consequential action is performed.

2. Security principles

Attribute's security design is guided by the following principles:

• Server-side enforcement. Access and execution controls are enforced at protected service boundaries rather than relying on interface visibility alone.
• Least privilege. Users, administrators, services, integrations, workers, and agents receive only the authority reasonably required for their function.
• Explicit data boundaries. Personal, organization, platform, document, integration, and AI-processing contexts are handled as distinct security contexts.
• Fail-safe behavior. Missing or unresolved identity, authority, tenant, boundary, or required security context does not become unrestricted access.
• Purpose limitation and minimization. Sensitive data is limited in logs, prompts, authorization metadata, diagnostics, and external-provider requests to what is necessary for the permitted purpose.
• Defense in depth. Authentication, authorization, workflow approvals, tool permissions, provider restrictions, validation, monitoring, and audit controls are layered where risk warrants it.
• Traceability. Security-relevant administrative and execution activity is designed to be attributable to the user, service, integration, workload, or agent responsible for it.

3. Shared responsibility

Attribute secures the Services and the providers Attribute selects to operate them. Customers remain responsible for matters within their control, including lawful data submission, endpoint security, identity-provider settings they manage, administrator selection, user lifecycle, role and permission configuration, connected-system permissions, approval design, and review of AI or automation output before consequential use.

A connected ERP, accounting platform, commerce system, data warehouse, identity provider, model provider, or other Customer-selected system may remain authoritative for designated records even when Attribute displays, processes, or synchronizes copies. Attribute does not treat access to a connected system as unrestricted authority inside Attribute, or vice versa.

4. Identity and authentication

Attribute uses identity and authentication services appropriate to the applicable user population and deployment. Authentication providers validate credentials and tokens; Attribute remains responsible for mapping authenticated identities to the relevant Attribute account, organization, role, permissions, and execution context.

Security controls include, as applicable:

• unique identities and account lifecycle controls;
• session and token validation;
• multi-factor authentication for privileged administrative access where required by policy and supported by the applicable authentication flow;
• protections against inactive, disabled, expired, or revoked access;
• controlled single sign-on and external identity-provider integrations; and
• separation of authentication identity from business authorization.

An email address, upstream OAuth scope, or provider-specific subject identifier does not by itself determine a user's business authority in an Attribute organization.

5. Authorization, tenant isolation, and privileged actions

Attribute applies server-side authorization to protected resources and operations. Authorization is designed around authenticated identity, organization or personal context, action, target resource, scope, and trusted server-side facts.

Depending on the Service, controls may include:

• organization and workspace isolation;
• role-, relationship-, resource-, and scope-based permissions;
• sensitive-field restrictions;
• approval limits and segregation-of-duties rules;
• explicit integration and service-account authority;
• bounded delegation and agent authority;
• independent tool permissions for consequential external actions; and
• audit of security-sensitive administrative changes and execution decisions.

Public access is modeled explicitly. Missing tenant, membership, or authorization data does not imply public or global access.

Customer administrators may be able to manage users, roles, permissions, integrations, AI settings, exports, retention, and other security-sensitive configuration. Customers should treat administrator access as privileged access and review it accordingly.

6. Data protection and minimization

Attribute maintains safeguards appropriate to the nature of the Services and the information processed. These safeguards include, as applicable:

• industry-standard transport protection for data transmitted over public networks;
• encryption at rest for production data stores and backups where supported by the hosting platform;
• restricted access to encryption keys and secrets;
• purpose-based data collection and processing;
• minimization of sensitive content in logs, prompts, diagnostics, and authorization metadata;
• masking or redaction where appropriate;
• restrictions on use of production data in non-production environments; and
• logical separation of Customer and Workspace data.

Derived information such as extracted fields, classifications, summaries, embeddings, recommendations, and confidence indicators is protected according to the sensitivity and source of the underlying data.

7. Credentials, secrets, and integrations

Passwords, API keys, tokens, service credentials, and integration secrets are handled according to their security characteristics. Where verification does not require recovery of a secret, one-way hashing is preferred. Recoverable credentials are protected through controlled storage, access restrictions, rotation, revocation, and audit appropriate to the credential type.

Browser applications are not intended to receive server-side integration credentials. Server-to-server integrations use scoped credentials or workload identities appropriate to the connection. Customer-selected integrations should be configured with the minimum permissions necessary for the enabled workflow.

A broad credential in a connected system does not automatically grant broad Attribute permissions. Integration identity, Attribute authorization, workflow, capability availability, tool access, and audit remain separate controls.

8. Infrastructure and workload security

Attribute uses managed cloud and infrastructure services for portions of the platform. Infrastructure controls are selected and configured according to risk and may include:

• environment separation;
• private or restricted service access;
• network and traffic controls;
• service and workload identities;
• configuration management and infrastructure-as-code;
• patching and dependency maintenance;
• resource and availability monitoring;
• restricted administrative access; and
• backup and continuity controls.

Production and non-production identities, secrets, data, and endpoints are separated as appropriate to the architecture. A cloud provider's certification or control environment applies to that provider's scope and does not independently certify Attribute's application or operational controls.

9. Secure development and vulnerability management

Attribute's development and release practices are designed to reduce security defects before production and to support controlled remediation when issues are discovered. Depending on risk, practices may include:

• typed interfaces and schema validation;
• input and output validation;
• peer review of material code changes;
• automated tests and contract compatibility checks;
• dependency, image, and infrastructure review;
• migration and rollback planning;
• separation of development and production access;
• vulnerability scanning or equivalent technical review;
• security testing and independent testing based on risk and maturity; and
• severity-based remediation tracking.

Security-sensitive features may be disabled or restricted until required dependencies, controls, monitoring, and operational procedures are available.

10. Logging, monitoring, and audit

Attribute records security and operational events appropriate to the Services and risk. Relevant events may include authentication, authorization, administrative changes, integrations, document access, agent activity, workflow actions, security events, and system failures.

Logs and audit records are designed to:

• identify the responsible user, administrator, service, integration, workload, or agent where applicable;
• support correlation across service boundaries;
• limit unnecessary secrets and sensitive content;
• use restricted access;
• resist ordinary user alteration; and
• support security investigation, operational troubleshooting, compliance, and accountability.

Customer-facing error messages are designed to avoid unnecessary disclosure of cross-tenant resource existence, memberships, policy relationships, credentials, or other protected details.

11. Document-assisted intake and document intelligence

Attribute may provide reusable document-assisted intake and document-intelligence capabilities for workflows such as customer or vendor onboarding, business applications, certificates, invoices, contracts, forms, and other Customer-authorized documents.

Where enabled, controls may include:

1. restricted upload authorization and supported file types or size limits;
2. private storage and quarantine of untrusted content;
3. malware and file validation before downstream processing;
4. controlled transfer to approved OCR, extraction, classification, or AI services;
5. field allowlists, confidence thresholds, source references, and validation rules;
6. filtering or rejection of document-borne instructions and prompt-injection-like content;
7. retention and deletion rules appropriate to the workflow; and
8. authorized user review before extracted information becomes authoritative business data or triggers a consequential action.

Document analysis produces assistance, candidates, or structured data for governed workflows. It does not by itself authorize an applicant, vendor, transaction, payment, filing, connected-system mutation, or other consequential decision.

12. AI, model-provider, and agent security

12.1 AI-context admission

Permission to view information does not automatically authorize processing it through every AI feature, sending it to every provider, or using it in a tool call. Where applicable, protected data must satisfy the relevant access, purpose, data-use, classification, minimization, provider, egress, and agent/tool controls before it enters model context.

A typical control sequence is:

candidate data
  -> resource authorization
  -> permitted purpose and data-use controls
  -> classification
  -> minimization or redaction
  -> provider and egress policy
  -> agent and tool authority
  -> model context

12.2 Model selection and routing

Attribute may support models and AI services from multiple providers and deployment patterns. Representative options may include Anthropic (Claude), Google (Gemini, including Google Cloud AI services where configured), OpenAI, SpaceXAI (Grok), OpenRouter, other direct or routed providers, and local, private, self-hosted, customer-hosted, or open-weight models.

Where the Services permit, an organization may assign approved models, provider routes, regions, or Customer-supplied credentials to specific workspaces, workflows, agents, tools, tasks, purposes, or data classifications. Attribute may separately assign approved models to Attribute-managed features.

Availability of a provider or model does not mean that provider receives data from every Customer or Service.

12.3 Provider classification

An Attribute-selected external model provider, host, or router that receives Customer Personal Data is treated as an Attribute Subprocessor and is subject to the Subprocessor List, the DPA, and applicable provider controls.

A Customer-selected provider account, API key, cloud project, endpoint, router, or private deployment is generally a Customer-directed service. A local or self-hosted model does not by itself create a third-party processor, although an external infrastructure host, managed inference operator, telemetry service, or remote-support provider may.

12.4 Training, retention, region, and fallback

Attribute does not use Customer Data or User Content to train generalized AI models without the separate affirmative authorization described in the Privacy Policy, Terms of Service, and DPA.

Provider selection and routing are designed to respect configured restrictions concerning model eligibility, provider eligibility, retention, training, region, data residency, security, and purpose. A routing fallback does not authorize use of a provider or endpoint outside those restrictions. If no eligible route is available, the request may fail or remain unavailable rather than use an unapproved route.

12.5 Agents and consequential actions

Where AI agents or automated workflows are enabled, their execution is bounded by the applicable identity, permissions, delegation, task scope, tool authority, workflow, approval, and Customer configuration. Model output does not itself authorize a payment, purchase, contract, approval, customer or vendor activation, connected-system mutation, or other consequential action.

AI output, extracted fields, recommendations, and confidence scores may be incomplete or incorrect. Appropriate human or governed review remains required for consequential, regulated, financial, legal, employment, safety, or other high-impact uses.

13. Retention, deletion, backups, and recovery

Attribute retains information according to the enabled purpose, Customer configuration and instructions, contractual terms, security needs, backup cycles, and legal obligations. Deletion processes are designed to address active records and, where applicable, object storage, indexes, caches, queues, derived data, model-related artifacts, logs, and backups according to documented schedules and legal-hold requirements.

Production data stores use risk-appropriate backup, access, encryption, restoration, and resilience controls. Customer-specific recovery objectives apply only when expressly stated in an Order Form or Service Level Agreement.

Recovery and replay mechanisms are designed to preserve tenant boundaries, current authorization, and audit integrity rather than treating an old authorization decision as an unlimited bearer grant.

14. Incident response and Customer notification

Attribute maintains an incident-response process designed to cover detection, triage, escalation, containment, investigation, evidence preservation, remediation, recovery, legal and privacy assessment, Customer communication, post-incident review, and corrective action.

For a confirmed Customer Personal Data Breach, Attribute will notify affected Customers as required by the DPA and applicable law, without undue delay after becoming aware of the breach. Information may be provided in phases as the investigation develops.

Customers should maintain current privacy and security contacts and reasonably cooperate with incident-specific requests involving their accounts, endpoints, identity providers, connected systems, or logs.

15. Personnel, subprocessors, and physical security

Personnel access to production systems and Customer Data is limited according to job need and is subject to appropriate confidentiality, identity, access, training, review, and deprovisioning controls. Support access is intended to be limited to the task and traceable where appropriate.

Material Attribute Subprocessors are subject to risk-based diligence and written data-protection and security obligations appropriate to the service. These obligations address matters such as purpose limitation, confidentiality, security, incident notification, deletion, international transfers, downstream providers, and independent use. Current providers are identified in the Subprocessor List.

Production infrastructure is primarily hosted in managed facilities operated by cloud or infrastructure providers with their own physical and environmental security controls. Attribute does not represent ordinary office locations as production data centers.

16. Assurance and compliance support

Attribute does not claim a security certification, attestation, or regulated-service status unless the applicable public documentation or signed agreement expressly identifies the certification, scope, period, and covered Services.

In particular, a provider's SOC, ISO, PCI, HIPAA, FedRAMP, or similar status does not automatically make Attribute certified or compliant for the same scope.

Subject to contract, confidentiality, proportionality, and security restrictions, Attribute may provide enterprise Customers with current security documentation, questionnaire responses, architecture explanations, and available independent-assurance materials. Information will not be provided in a manner that would expose another Customer's data, credentials, sensitive attack paths, or protected provider information.

17. Customer security responsibilities

Customers and administrators should:

• use strong authentication and available multi-factor authentication;
• protect endpoints and remove access promptly when roles change;
• assign administrators carefully and review users, roles, permissions, approval limits, delegations, integrations, and sensitive access regularly;
• submit only information necessary for enabled purposes and avoid unsupported regulated data;
• protect API keys, integration credentials, exports, and connected-system accounts;
• configure connected systems with least privilege;
• validate critical records, AI output, extracted values, pricing, credit, financial, legal, regulatory, and operational decisions before reliance;
• configure approved model/provider allowlists, Customer-supplied credentials, regions, routing and fallback rules, retention and training settings, and local/private model operations according to workflow sensitivity;
• maintain current privacy and security contacts; and
• use available retention, export, deletion, and audit capabilities appropriately while preserving records that must be retained outside Attribute.

18. Security contact and vulnerability reporting

Security questions and vulnerability reports may be sent to the Security email below. Privacy and DPA requests may be sent to the Privacy email.

When reporting a suspected vulnerability, include the affected Service, environment, time observed, reproduction details, potential impact, and a secure method for follow-up. Do not access, retain, alter, or disclose information beyond what is reasonably necessary to demonstrate the issue.