Agent-readable docs index: /llms.txt. Full docs in one file: /llms-full.txt. Download /docs.zip to grep all markdown files locally.

Audit and investigation

Audit shows owners and admins who used which app, through which AI client, and with what outcome. It does not store the request details or data returned by the connected app.

Read outcomes

  • Successful: Stackyapper authorized the call and the app completed it.
  • Denied: a Stackyapper access or confirmation check rejected the call.
  • Error: the authorized call did not complete, often because of connection, provider, or request failure.
An empty result does not prove that no activity exists outside the selected workspace, customer, date, or filters.

Retention

Audit history is retained for 90 days on Standard and 365 days on Business. A retention override can also be set for a workspace; the portal shows the effective retention window for a selected workspace. When an MSP views all customers together, it shows the range of workspace retention policies; each event remains subject to its own workspace policy. Date presets include the longest retention window in that authorized view. Managed customer workspaces inherit the managing account's plan.

Search activity

Use Search selected history to search names, email addresses, apps, tools, clients, and event IDs across the selected retained history. It searches all matching records, not just the first page. For one person, use Find a person and select their name and email from Person, then choose Apply filters. People with the same name remain separate records.
Event times are shown in each viewer’s local time zone. The page starts with a 30-day range; choose another range to investigate older retained activity. MSP admins with access to managed customers can also select a customer. The page shows the applied range, total matches, and how many events have loaded. Load more continues the same view in pages of 100, newest first.
The retention period and available history are different: a 365-day policy does not create records from before collection began. Managed customer overrides can also affect which records remain available.

Search audit history from an AI client

Workspace owners and admins can discover stackyapper_search_audit_events through the tool catalog and execute it through stackyapper_execute_read_tool. Ask your AI client to find audit events for a person, app, or date range. The call checks your current workspace membership and administrator role each time; being connected to an AI client does not grant audit access.
The tool accepts these filters:
FilterUse
qSearch text, including person name or email, app, tool, client, or event ID; up to 200 characters.
user_idSelect one recorded person by ID.
customer_idSelect a managed customer within your authorized scope. Customer admins remain limited to their own workspace.
from, toSet the date range; the default is the last 30 days. Retention still limits available records.
service, tool, clientFilter the app, operation, or recorded client.
statussuccess, error, or denied.
risk_classread, write, destructive, or credential_sensitive.
limitRequest 1–50 events per page; the default is 25.
cursorContinue using the previous response's pagination.next_cursor. Keep the same filters when continuing.
For example, search recorded access for one person without retrieving business content:
{ "tool_name": "stackyapper_search_audit_events", "arguments": { "q": "Alex", "status": "denied", "limit": 25 } }
Results include safe event metadata in events, a total_matching count, the applied date filters, retention details, and pagination.has_more / pagination.next_cursor. A page is not the whole history when has_more is true. Arguments, returned app content, raw provider errors, and IP addresses are excluded. This search does not export audit history or change the Business CSV export entitlement.

Inspect an event

Select View beside an event to see its recorded identifiers, actor, app, connection, tool or action, outcome, risk, client, execution origin, trace, and timing. Older records may say Not recorded for fields added later.
Client-reported names and versions help investigations but do not prove which application or person controlled the client. Use the saved person and connection identifiers to distinguish similarly named records. After an account is deleted, its previous identity may no longer be available.
Routine errors use standardized reasons. Historical request details and complete provider error bodies are not shown. Depending on workspace notification settings, network context may be stored in full, truncated, or omitted. See Notifications for the client-address control.

Verify a first call

After a first connection or any material permission change, run one harmless read-only tool call as the affected user, then confirm it in Audit. This is the canonical verification ritual; other pages link here.
The portal Audit log listing eight tool calls with time, organization, user, tool, connection, client, outcome, and duration columns; outcomes include success, denied, and error.
Every row names the actor, the tool, and the connection it ran through. Arguments and returned data are not recorded, which is why a denied row tells you a restriction held but not what was asked for.
  1. Open Audit after completing the read.
  2. Confirm the workspace and approximate time.
  3. Confirm the actor and AI client.
  4. Confirm the app and tool.
  5. Confirm the outcome and duration.
When contacting support about a specific call, include the details shown on the audit entry—workspace, app, tool, actor, outcome, and time. Request and result identifiers, when present, are shown on the audit entry detail.

Investigate a denied call

Check:
  • Whether the app is available and connected.
  • The user's effective group and direct policy.
  • Explicit tool restrictions.
  • Whether confirmation was required but not completed.
  • Whether the call was made in the intended workspace.
Do not broaden an entire app grant until you identify the exact missing tool.

Investigate an error

Open the app first if its state is Needs attention. Otherwise compare the Audit timestamp with the provider's own service health and authorization logs. Retry only with a harmless read until the connection is healthy.

Export

Workspace CSV export requires an owner or administrator with the Business plan's export entitlement. A person's own-record export has a separate access policy.
Apply your filters, then select Export CSV. The download uses the applied search, person, customer, dates, and other filters. It retrieves all pages of the selected snapshot rather than stopping silently at 10,000 records. New activity arriving during the download is left for your next export. You can cancel while it runs. A failed or cancelled download does not save a partial file.
Browser exports are limited to 64 MB. For a larger investigation, export separate shorter date ranges and keep them together. Older direct-download and individual person export links require narrower dates when more than 10,000 records match; they return an explicit error instead of an incomplete file.
The CSV includes event and person IDs, UTC time, organization, person name and email where available, role, app, connection, tool or action, client, outcome, duration, risk, origin, trace, and standardized error information. Values that could be interpreted as spreadsheet formulas are escaped. Export initiation is recorded; it is not proof that a recipient saved or reviewed the file.
Store exports in an approved location with access restrictions and your company's retention policy. Stackyapper's retention settings do not delete downloaded copies.

Evidence for business reviews

Audit supports investigations into activity routed through Stackyapper, access denials, and recorded administrative changes. It does not provide a complete history of actions taken directly in another app or identify every document or ticket returned by an app. It does not retain raw prompts or returned app content. Authentication history is not a complete tenant sign-in log.
Use these records alongside your identity provider, connected apps, incident records, and documented review procedures. Requirements depend on your systems, contracts, and applicable rules. For example, NIST leaves audit retention to the organization's requirements; HIPAA's six-year rule concerns required compliance documentation and should not be read as a universal six-year raw-log rule. See NIST audit controls and HHS Security Rule guidance.
The audit database is not an independently locked archive. This feature does not include legal holds, a complete authentication lifecycle feed, or a guarantee that all activity has been captured without loss. If your review requires a protected archive, a longer preservation period, or provider-native audit events, arrange those controls separately. A retention period or CSV export alone is not compliance certification.

Sensitivity labels

The Tool sensitivity column in sensitive activity combines the operation’s risk class (such as read, write, or destructive) with its data-sensitivity labels. Use the information icon beside the column heading for a short explanation.
LabelMeaning
PIIPersonally identifiable information, such as names, email addresses, or phone numbers.
SecretsCredential-related data, such as passwords, API keys, or tokens.
FinancialFinancial or billing-related data.
Tenant adminWorkspace or tenant administration capabilities.
External sendOperations that send information to an external recipient or destination.
These labels classify what a tool may handle. They can come from reviewed operation declarations, classification rules, or overrides. They are not findings from scanning the actual request or response. A secrets label does not prove that a password was returned, stored in the audit log, or exposed. Likewise, a successful call describes execution outcome, not a data-leak finding.
For example, a member-search tool can carry both PII and secrets labels while its primary risk remains read. The labels alone do not identify which fields were returned by an individual search. Confirmation is shown separately: Not required means that call did not require confirmation, not that its data was classified as non-sensitive.

Source sensitivity and returned data

A tool classification may describe source data, input fields, or capabilities. It does not describe the contents returned by a specific execution. An output projection can exclude sensitive source fields while the tool retains its conservative sensitivity classification for policy enforcement.
For cw_search_members, the current reviewed projection allows only the member ID, license class, inactive flag, daily capacity, utilization-reporting flag, and timesheet-entry flag. Its source-response classification includes PII and secrets; the projection excludes names, contact details, security roles, and credential fields. This describes the connector contract, not proof of the payload returned by a historical call.
A missing tag is not proof of non-sensitive data. The UI must not claim that information was detected, returned, filtered, or exposed without evidence for that specific claim.