Security and Architecture

Nothing is installed on the machine. The add-in uses Microsoft's current web add-in framework, so it runs as a static front-end web application inside Excel's sandbox rather than as an installed desktop application.

• There is no MSI or EXE and no locally installed binary.
• The add-in interacts with the workbook only through the supported Office JavaScript API. It can read the open workbook and write cell values and citation links, but it does so through Excel's controlled API surface, not through direct system access.
• This is a materially narrower footprint than a traditional installed add-in, which typically has broad access to the Excel instance and the host machine.

The framework itself is the primary control. Because the add-in runs in Excel's sandbox with no system-level access, a compromise cannot reach the operating system, the file system, or other applications.

• Capabilities are constrained to what the manifest declares.
• The add-in cannot access the COM or user-system layer, cannot read from the local disk, and cannot write files to the workstation.

In practical terms, the worst case is contained within the boundaries Excel enforces on any web add-in, rather than extending to the host environment.

No. The add-in cannot create any macro and cannot execute arbitrary code.

• Everything the add-in can access is defined in the Microsoft manifest. If a capability is not declared there, the add-in does not have it.
• It has no access to the COM or user-system layer. It cannot download anything to the user's machine and cannot read from the local disk.

This directly addresses the classic malicious-macro attack pattern, where an Office file carries VBA that fetches and runs a payload. The add-in has no VBA capability and no path to the file system, so that pattern does not apply.

The manifest defines the add-in's entire permission set and cannot be changed at will. Any change must be submitted to Microsoft and pass Microsoft's review before it takes effect.

• The permission set cannot be silently widened. An attacker who wanted the add-in to perform a riskier action would have to get a modified manifest through Microsoft's approval process first.
• The manifest is available for independent inspection at https://addin.daloopa.com/manifest.xml.

If a future manifest requested a capability the current one does not have, that request is visible and gated by Microsoft's process, rather than arriving quietly through a routine update.

To push a malicious update, an attacker would need to access the add-in listing, submit an altered manifest, and get approval from the Microsoft security team. That analysis takes on average at least a week and requires communication with Daloopa's internal security team, making it impossible to pass unsupervised. No malicious change can reach customers automatically or silently.

• Updates are delivered automatically after Microsoft approves the manifest, ensuring users are always on the latest version.
• A malicious change to the add-in's capabilities would require a new, Microsoft-approved manifest, adding a second independent checkpoint outside Daloopa's control.

A successful attack would therefore have to defeat both your administrators' control over deployment and Microsoft's manifest review.

Development-process integrity is covered as part of a full vendor assessment, and we are happy to complete your standard security questionnaire and share supporting documentation.

In the web add-in model, the manifest and Microsoft's review act as an external control on what any build of the add-in is permitted to do. Review teams generally find this line of questioning becomes less load-bearing than it is for an installed application, because the permission boundary sits outside Daloopa's codebase entirely.

Links point only to Daloopa's own web application on a single Daloopa domain. The add-in cannot produce an arbitrary link.

• The link structure is fixed. The only element that varies is an identifier specifying which data point is being referenced; the web application then serves the corresponding content.
• Because every link resolves to one Daloopa domain, there is no need to whitelist a broad or changing list of external domains.

This removes the risk of a link being altered to point at a malware distribution site, because the destination is not a free-form URL to an arbitrary location on the internet.

No. The link opens a Daloopa-rendered copy of the source document, hosted by Daloopa, not the original file at a third-party location.

• Daloopa stores and renders its own copy of the underlying document. Users are never routed directly to an external investor-relations page or third-party PDF.
• This is a deliberate design choice: it keeps citation traffic on a known, controlled surface and avoids exposing users to arbitrary external content.