How Cloud Agents Help Review Changes to a Security Master

Amol Kapoor opens with a change in finance: more capital is flowing into private assets, including land, energy infrastructure, data centers and shares in private AI companies. He cites secondary-market volume and forecasts for alternative assets as illustrations of a broader shift, not as guarantees about future growth.

Kapoor attributes that shift to several forces. Alongside demand for infrastructure that supports AI, he points to companies staying private longer, regulatory considerations and investors seeking opportunities outside heavily contested public markets.

If more of the economy is held privately, Kapoor argues, buying an index of public stocks no longer gives an investor exposure to the whole market. That encourages more investors to seek private assets, which in turn makes the practical problem of managing their data more important.

The details of a private investment may be scattered across PDFs, Box folders, emails and call transcripts. Even basic questions such as the number of shares owned, a strike price, the purchase price of land or the rights attached to a deal can require searching several documents.

Kapoor introduces Nori Agentic, which builds cloud agents, and explains that the talk focuses on using them to manage and audit a firm's investments. His co-founder and CTO Clifford Ressel, who has experience in back-office finance, takes over to explain the security master.

Ressel describes a security master, or sec master, as the master database of the securities and instruments in an asset manager's investment universe. It serves as a starting point for risk management, profit-and-loss accounting, regulatory compliance and other business-critical analysis.

When sources disagree about a value, the ideal process catches the conflict before it enters the master data. Teams can return to the sources or examine the mapping logic and correct upstream problems before those errors spread to downstream analysis.

Ressel calls this an organizational primitive: a layer between data producers and consumers where standards, visibility and quality checks can be enforced. The implementation could be a complex lakehouse with many tables or a single denormalized source of truth.

Public markets have several coordinating institutions. Vendors provide identifiers such as FIGIs and RICs, while numbering agencies supply ISINs and CUSIPs for regulatory and other purposes. Mapping these identifiers to an internal view lets firms join outside data, report holdings and model risk.

Even a familiar public stock illustrates the complexity. Google has GOOG and GOOGL share classes; information might be reported at the legal-entity level, the security level or across different exchanges. A firm must map those different granularities correctly before it can combine the data.

Ressel compares the problem to a date-time library: it looks straightforward when someone has solved it well, but the implementation contains many edge cases and complex conventions. A denormalized table can give incoming data enough identifier mappings to reach the right internal record even if only some identifiers are present.

Structured data and a well-defined internal ontology can help coding agents build new analyses, Ressel says. The harder case is a source with no standard identifier: someone must determine manually which entity it describes and whether the mapping is correct.

Consider lending to a company building a power plant or buying nearby land. There may be no shared identifier, central regulator of the information structure or vendor API with a ready-made ontology. Repayment schedules, collateral and amendments live in individual agreements, so each asset brings its own documents and data work.

Kapoor returns to the operational consequence. Private assets still need standardization, cleaning and auditability even when their documentation is inconsistent. Risk analysts should not have to search every document themselves to establish whether the data they receive is correct.

He describes a Fortune 200 asset manager whose data engineering team checked day-over-day changes to a security master. In his example, a table of 50,000 assets and around 200 columns produces a continuing stream of individual cell changes for people to investigate.

Investigators compared each changed cell with documents and other sources to decide whether it was valid. A price, name, bankruptcy, ownership change or renegotiated contract could each trigger a review. Kapoor says the work averaged about an hour per change; he corrects an initial statement of hundreds of thousands of monthly hours to hundreds or thousands.

Kapoor defines a cloud agent as a coding agent operating in a remote environment rather than on a user's laptop. He says that environment can support scheduled work, observability, transparency and audit requirements, so the agent can start when new security-master data arrives.

In the described deployment, a change triggers a Nori agent using a locally deployed open-source model within the customer's environment. The agent has instructions and access to selected sources, including PDFs in Box, public data APIs and a limited portion of email, to investigate the origin of the change.

The agent assembles an explanation, cites supporting sources and recommends retaining or discarding the change. It then alerts the owner of the changed cell in Slack. A person reviews the recommendation and can perform further research; the agent is not the final authority.

Kapoor says the agent reduces the human portion of a typical check from around an hour to about five minutes because it performs the document search and assembles the supporting case. This is the team's account of its particular workflow, not a general benchmark for all asset managers.

How does the agent gain domain expertise? Kapoor compares it with onboarding an analyst: provide written guidance on where documents live, which sources to trust and how to assess changes. Teams can update natural-language Markdown instructions rather than building a separate bespoke agent for every task.

He suggests pairing a general agent with configurations such as skills or AGENTS.md files. Much of the specialization comes from the environment, credentials, available tools and instructions supplied to it, rather than a unique underlying orchestration system for each workflow.

Kapoor likens the resulting security master to a database surrounded by small automated cleaners that watch for issues and surface them. He argues that the same pattern can move enterprise work from a reactive model, where a person asks an agent for help, to one where agents proactively bring people analysis and recommendations.

For that approach to scale, he recommends common infrastructure for orchestration, security and integrations across security-master, audit and code-review agents. Each task can retain its own triggers, tools, context and company-owned instructions while sharing the underlying platform.

His first lesson is that AI adoption is a collaboration problem: customers want solutions while engineers often offer building blocks. Nori found progress when domain experts could connect the capabilities of cloud agents to a concrete problem they already had.

Second, Kapoor recommends aiming for substantial automation while keeping a human involved. Rather than insisting that an agent complete every case end to end, a five-minute human review can make many valuable workflows practical and preserve accountability, especially in finance.

His final lesson concerns accidental complexity: work caused by the way systems evolved, such as the same data appearing in different formats, rather than by the intrinsic difficulty of the underlying problem. He sees agents as useful for this repetitive, high-effort work, freeing people to spend more time on genuinely difficult decisions.