Armalo Versus SOC 2 Reports For Agents: Why A Static Audit Cannot Govern A Self-Modifying System

TL;DR

SOC 2 reports are annual or semi-annual snapshots of an organization's controls. The methodology assumes the system being audited is stable enough that a snapshot is meaningful for the period covered. Agents are not stable. They update weekly. Their behavior shifts with model upgrades, prompt changes, tool additions, and capability expansions. A SOC 2 report on an agent is a photograph of a moving target, valid for the moment it was taken and progressively less meaningful as time passes. Continuous attestation is the agent-equivalent of SOC 2: pacts that codify external commitments, multi-LLM jury that continuously evaluates behavior, composite score that reflects current state, public Trust Oracle that exposes it in real time. SOC 2 still has a role for the static parts of the operator's posture. Continuous attestation handles what SOC 2 cannot.

A failure mode you have probably already lived through

A series-B SaaS company building agentic workflows for healthcare administration completes their first SOC 2 Type II report in March. The report is rigorous. The auditor spent three months on it. The findings are clean. The leadership team is delighted. The sales team finally has the report buyers have been demanding for six months. The first deal that had been waiting on it closes in April. The next deal closes in May. The sales motion accelerates because the SOC 2 unblocked the security review at every prospect.

In June, the team ships a major model upgrade. The agent moves from one frontier model to a newer one with substantially different behavior. Most things improve. A few things change in ways the team did not anticipate. The agent's refusal patterns shift slightly. Its handling of certain edge cases is different. Its scope creep on a particular kind of request is new. Internal evals catch most of this. The team is iterating fast. They are proud of the velocity.

In September, a major customer's security team comes back for a quarterly review. They ask the obvious question: is the agent still doing what it was doing in March when the SOC 2 was issued? The team's honest answer is no, it has been substantially upgraded since then, but it is doing more and better things. The customer's security team is sympathetic but uncomfortable. The SOC 2 covers a system that no longer exists. The current system has not been audited. The auditor will not issue a fresh report until the next annual cycle. The customer asks whether the team has any continuous evidence that the upgraded agent is still operating within the controls that were attested to. The team has internal monitoring but no third-party signal.

The customer's security team makes a reasonable but consequential decision. They will not allow the upgraded agent into production for the next three quarters of their fiscal year. They will revisit when the next SOC 2 covers the upgraded system. The deal continues but the team's velocity at this customer slows to a crawl. They cannot ship updates without each one triggering a review. The SOC 2 that was supposed to be the unlock has become a constraint, because the cadence mismatch between agent updates and audit cycles makes the static report progressively less useful.

This is the gap. SOC 2 is built for systems that change slowly. Agents change weekly. The static audit cannot govern the self-modifying system. The team needs something else: continuous attestation that updates as the agent updates, produced by infrastructure that can keep up with the cadence. This post is about why the gap is structural, why patching SOC 2 to be faster will not work, and what continuous attestation has to look like for it to actually serve the same trust function for agents that SOC 2 serves for static infrastructure.

What SOC 2 actually is, precisely

SOC 2 is a reporting framework developed by the AICPA for evaluating service organizations' controls relevant to security, availability, processing integrity, confidentiality, and privacy. The framework is built around five Trust Services Criteria. An auditor evaluates the organization's controls against the relevant criteria, tests their operating effectiveness over a period (Type II) or at a point in time (Type I), and issues a report describing the controls and the auditor's opinion on whether they are designed and operating effectively.

The framework's strengths are real. It is a common language buyers and sellers can use to evaluate trustworthiness. It forces operators to formalize their controls. It surfaces gaps that an organization might not have noticed. It produces a document that can be shared in security reviews to short-circuit the same questions being asked from scratch by every customer. For static SaaS infrastructure, where the controls themselves are stable across the audit period, it is well-designed and has earned its dominance.

The core methodology is sampling and testing. The auditor identifies the controls. They sample evidence of the controls operating over the period. They test the samples for effectiveness. They form an opinion. The methodology assumes the controls themselves are stable. A change-management control that requires dual approval for production deploys was the same control in January as it is in December. The samples from across the year are evaluating the same control. The opinion at the end of the period is meaningful because the underlying system held still.

The second core property is the document as artifact. The SOC 2 report is a long, detailed document that buyers consume during security reviews. The document is the deliverable. Buyers read it, ask questions about it, sometimes negotiate over it, and either accept it or do not. The document is the interface between the operator's controls and the buyer's evaluation. This works because documents are the right medium for static controls that buyers need to understand once and then rely on for the period of the report.

The limit is that everything about this design assumes the system being audited is stable across the period. When the system updates weekly, the methodology breaks. The samples from January are evaluating a different system from the samples from December. The opinion at the end of the period is incoherent because there is no single system to opine on. The document captures a snapshot that is already obsolete by the time the buyer reads it. None of this is a flaw in SOC 2. It is a flaw in applying SOC 2 to systems that violate its core assumption about stability.

Why agents violate SOC 2's core assumption

The assumption that the system is stable across the audit period was reasonable for the systems SOC 2 was designed for. Operating systems update on a schedule. Network controls are configured once and then maintained. Access provisioning processes get formalized and followed. Database backup procedures get documented and run on cron. None of these change weekly in ways that affect the controls. The controls themselves are stable. Sampling them across a period is meaningful.

Agents change weekly. The team ships prompt updates because they found a better way to phrase an instruction. The team upgrades the underlying model when a new version comes out. The team adds a tool because a customer needed an integration. The team expands capability because the use case grew. Each of these changes can affect the agent's behavior in ways that propagate through to controls. The accuracy floor that the agent was meeting in January might not be met in March because of a model upgrade. The refusal patterns that were stable in February might shift in May because of a prompt change. The scope of what the agent will attempt might expand in June because of a tool addition.

The second source of change is environmental. The agent operates over inputs that come from the world. The world drifts. New patterns of input emerge. New attempts to manipulate the agent appear. New edge cases surface. Even without any team-driven change, the agent's behavior over a year will look different from the agent's behavior at the start of the year because the input distribution has shifted. SOC 2's methodology assumes the inputs are similar enough that sampling across the period gives a representative picture. For agents this assumption is weaker than for static systems.

The third source of change is emergent. Agent behavior is not fully predictable from the components. Prompt changes interact with model behavior in non-obvious ways. Tool additions can shift the agent's reasoning patterns even on tasks that do not use the new tools. Memory accumulation changes future behavior. The system is more like a biological organism than a piece of static infrastructure. It evolves. Audit methodologies designed for static infrastructure do not transfer cleanly to organisms. The methodology has to evolve with the subject.

The practical implication is that any audit framework applied to agents has to be continuous to be meaningful. A static report is structurally limited because the subject is not static. The buyer who relies on the static report is relying on a snapshot of a system that no longer exists. The auditor who issued the report is not at fault. The framework is not at fault for what it was designed to do. The mismatch is in applying a framework built for static systems to systems that are not static. The right response is to add a continuous attestation layer, not to keep stretching SOC 2 to do something it was not built for.

What continuous attestation actually looks like

Continuous attestation is the design pattern that addresses the cadence mismatch. The third-party evaluator runs a permanent evaluation pipeline against the agent. The pipeline samples production behavior. It runs adversarial probes. It evaluates against the agent's pact. The verdicts feed a trust score that updates in real time. A buyer querying the trust signal gets the current state, not a snapshot from months ago. When the agent ships an update, the score reflects the new behavior within hours or days, not after the next audit cycle.

The foundation is the pact. The pact codifies the external commitments the agent is bound by. Accuracy floor, refusal patterns, latency ceiling, scope, escalation rules, economic consequences for violations. The pact is the equivalent of the controls in SOC 2: the things being attested to. Unlike SOC 2 controls, the pact is structured, machine-readable, signed, and versioned. When the team ships a new agent version, the pact may be unchanged or it may be updated. Either way, the version is explicit and the attestation is against the specific version that is live.

The evaluation methodology is the multi-LLM jury. Multiple judge LLMs from different model families independently score the agent's behavior. The top and bottom 20% of scores are trimmed to suppress correlation and outliers. The remaining scores are aggregated into a verdict. The methodology is public, reproducible, and uncontrolled by any single party including the platform operator. This is what makes the verdict credible enough to be the basis of trust. No single party can manipulate the verdict by tilting any one component.

The trust signal is the composite score. The score aggregates verdicts across many evaluations into a continuously updated estimate of the agent's pact compliance. The score has dimensions: accuracy, self-audit, reliability, safety, security, bond, latency, scope honesty, cost efficiency, model compliance, runtime compliance, harness stability. The dimensions allow buyers to weight what matters most for their use case. The composite is the headline. The dimensions are the diligence material.

The interface to buyers is the public oracle. The Trust Oracle pattern exposes the current trust state at a stable URL. Buyers query it. Their security teams query it as part of vendor reviews. Their procurement systems query it as part of automated risk scoring. The oracle replaces the SOC 2 PDF. Instead of a document the buyer reads once during a review, there is a real-time signal the buyer can query at any decision point. This is what makes continuous attestation actually continuous on the consumption side, not just the production side.

The role SOC 2 still plays

The argument is not that SOC 2 is obsolete. SOC 2 still does important work for the static parts of the operator's posture. The change management process. The access control framework. The incident response procedure. The encryption practices. The vendor management discipline. These are static enough that an annual snapshot is meaningful. They are exactly what SOC 2 was designed for. Operators serving regulated buyers will continue to need SOC 2 reports because buyers will continue to need them for the static layer.

The correct framing is that SOC 2 covers the operator's static controls and continuous attestation covers the agent's dynamic behavior. The two layers do different jobs. SOC 2 attests to whether the operator has a sound change management process. Continuous attestation attests to whether the specific agent that resulted from that change management process is currently behaving in pact. Both are necessary. Neither is sufficient.

The practical implication is that operators need both. The SOC 2 audit covers the operator-level controls. The continuous attestation infrastructure covers the agent-level behavior. The buyer's security review consumes both. They consume the SOC 2 report once per audit cycle. They consume the trust signal continuously, especially before high-stakes decisions or on a defined cadence. The two together give the buyer a complete picture: the operator's posture is sound (SOC 2) and the agent's current behavior is in pact (continuous attestation).

The operational implication is that the SOC 2 report should reference the continuous attestation infrastructure. The change management process for agents should be documented in the SOC 2 report and should explicitly include the continuous attestation pipeline as a control. The buyer reading the SOC 2 report should see that the operator runs continuous attestation on their agents and should be pointed at the trust oracle for current behavioral attestation. This is the integration pattern. SOC 2 is the static frame. Continuous attestation is what fills the frame for the dynamic parts of the system.

Why patching SOC 2 to be faster will not work

A tempting response to the cadence mismatch is to make SOC 2 faster. Quarterly reports instead of annual. Targeted bridge letters that cover specific changes. Continuous SOC 2 monitoring tooling. These are interesting and they help at the margins. They do not solve the underlying problem because the underlying problem is structural, not cadence.

SOC 2's methodology is built around an auditor evaluating controls and forming an opinion. The auditor is a human professional applying judgment. The cycle of plan, sample, test, review, and opine takes time. Compressing it from twelve months to three months is feasible but expensive. Compressing it to weeks or days is not feasible because the human judgment in the loop has its own cycle time. The methodology cannot be sped up below the speed at which the humans can responsibly form opinions.

The second structural issue is what the audit produces. The SOC 2 report is a document that humans read. Documents are appropriate for opinions formed across periods. Real-time trust signals are not appropriate for documents because the format does not match the consumption pattern. A buyer who needs to query the agent's current trust state at the moment of a routing decision is not going to read a document. They need an API. The mismatch is between the deliverable format and the consumption pattern. Making SOC 2 faster does not change the deliverable format.

The third structural issue is what the audit covers. SOC 2 covers controls at the operator level. The agent's behavior is downstream of those controls but is its own concern. Making SOC 2 faster does not give it a methodology for evaluating agent behavior at the necessary granularity and frequency. That methodology is what the multi-LLM jury and continuous attestation pipeline provide. SOC 2 is not built for this evaluation and stretching it to be is wrong-shaped.

The right answer is to keep SOC 2 doing what it does well and add continuous attestation as a separate layer that does what SOC 2 cannot. The two layers compose. They do not compete. The buyer consumes the SOC 2 report for the operator-level controls and the continuous attestation signal for the agent-level behavior. The operator runs both pipelines because both are necessary for serious enterprise sales. The audit firm continues to produce SOC 2 reports because those are still valuable. The trust infrastructure provider produces the continuous attestation. Both have a sustainable business. Neither has to do the other's job.

The economic logic of continuous attestation infrastructure

Why does continuous attestation need to be its own infrastructure layer rather than something each operator builds in-house? The answer is the same as for any infrastructure category: shared infrastructure is dramatically more efficient than per-operator builds, and it is more credible because it is structurally neutral.

The build cost is high. A continuous attestation pipeline requires multi-judge orchestration across multiple LLM providers, trim and aggregation logic, score calibration, time-decay handling, anomaly detection, dispute resolution, certification tier management, public oracle infrastructure, on-chain settlement integration. Each piece is non-trivial. The integrations between them are where most of the engineering complexity lives. Building this in-house is the same kind of decision as building your own database. Possible. Almost never wise. The infrastructure category exists for a reason.

The credibility issue is structural. An attestation produced by infrastructure the operator runs is not credible to counterparties for the same reason that internal evals are not credible. Self-attestation is structurally weak no matter how rigorous the methodology. The attestation has to be produced by infrastructure the operator does not control. This means the infrastructure has to be third-party. Third-party infrastructure can be either commercial (a trust layer provider) or open (a public protocol) but cannot be owned by the operator. The economic model has to support a sustainable third-party operator that the buyer can rely on without having to verify the operator's neutrality.

The network effects are large. As more agents are evaluated by the same infrastructure, the methodology improves. Judges get better. Trim logic gets refined. Calibration gets more accurate. Certification tiers become more meaningful. This is the same dynamic as the credit bureaus, where the value of the trust signal grows with the number of participants being evaluated. Per-operator infrastructure cannot match this because each operator is evaluating a small population in isolation. The shared infrastructure is structurally on a faster improvement curve.

The economics also reward the operator that adopts the shared infrastructure. The operator does not have to build the infrastructure. They get the credibility for free because the infrastructure is already trusted by buyers. They benefit from the methodology improvements as the infrastructure matures. Their cost is amortized across many production calls. The combination of lower cost and higher credibility is what makes shared infrastructure adoption inevitable in any infrastructure category. Continuous attestation will follow the same path. The operators who adopt early will have a competitive advantage during the transition. The ones who insist on building in-house will discover that they are spending more for less credibility, which is a losing position.

What this means for security reviews

The practical consequence for buyers is that security reviews change shape. The traditional security review reads the SOC 2 report, asks follow-up questions, evaluates the answers, and approves or rejects. The cycle is bilateral and sequential. It is appropriate for static systems where the answers do not change between reviews.

The agent-aware security review is structured differently. The buyer reads the operator's SOC 2 report for the static controls. The buyer queries the Trust Oracle for the agent's current behavioral state. The buyer evaluates both. The approval is conditioned on both. Importantly, the approval is also conditioned on the trust signal staying within bounds. If the agent's score drops below threshold during the relationship, the buyer's risk posture has changed and they may want to reevaluate. This is not paranoid. This is the right design for systems that change.

The second shift is in how buyers automate. Many large buyers are building procurement and integration systems that consume vendor risk signals programmatically. SOC 2 reports are hard to consume programmatically because they are documents. Trust scores from a public oracle are easy to consume programmatically because they are structured data. Buyers will increasingly route procurement decisions and integration approvals through automated risk scoring that incorporates the trust signal. Vendors who do not have a trust signal will be filtered out before a human ever reviews them. This is already starting to happen. It will accelerate.

The third shift is in negotiation. SOC 2 reports are negotiated infrequently and the negotiations are typically about scope, timing, and exceptions. Trust scores are not negotiated because they are produced by infrastructure neither party controls. The asymmetry is interesting. Operators cannot negotiate their score down to acceptable levels. They have to actually be in pact. Buyers cannot pressure operators to inflate scores. The score is what it is. The negotiation moves to other dimensions: pricing, terms, support. The trust dimension is settled by the infrastructure, which simplifies the relationship in ways that benefit both sides.

The operator's strategic implication is to invest in the trust signal aggressively. Score improvement is competitive advantage. Maintaining a high score over time is a moat. Falling below a competitor's score loses deals. The dynamic is the same as credit scores in lending: the score determines access to markets and pricing, and operators have strong incentives to maintain it. This is healthy market dynamics. It is what makes the trust infrastructure work as economic substrate. SOC 2 alone cannot create these dynamics because the report is too lumpy and too slow.

How procurement and security teams actually consume the two signals

The operational difference between SOC 2 reports and continuous attestation shows up most clearly in how buying organizations consume each signal. The consumption pattern reveals why the formats and cadences matter, and why operators who only have one of the two layers struggle in deals that need both.

SOC 2 reports are consumed during onboarding. The security review team requests the report. They read it. They check the auditor, the period covered, the scope, the controls, the exceptions. They write up their findings. They sign off or push back. The entire cycle takes days to weeks depending on the organization's process. Once approved, the report sits in the vendor risk file. Reference is made to it during periodic reviews. It is rarely consulted between reviews because the document does not change between annual cycles. The consumption pattern is high-attention at onboarding, low-attention thereafter, until the next renewal triggers a fresh review.

Continuous attestation is consumed differently. The trust signal is queried programmatically as part of automated workflows. The procurement system queries it before approving an integration. The security tooling queries it on a defined cadence to detect drift. The runtime systems query it before high-stakes routing decisions. The consumption pattern is low-attention per query but continuous over time. The signal is checked many times for every time a SOC 2 report is read. The buyer's relationship with the signal is more like the relationship with a credit score than with an audit report.

The difference in consumption pattern drives the difference in format. SOC 2 reports are documents because human reviewers consume them. Trust scores are API endpoints because automated systems consume them. Trying to use a SOC 2 report in an automated procurement workflow is awkward at best because the document was not designed for it. Trying to use a trust score in a human-led security review is also awkward because the score is structured data without the prose context that reviewers expect. The two formats serve their respective consumption patterns and do not substitute for each other.

The operational implication for vendors is that they need to surface both effectively. The SOC 2 report should be available to security reviewers in their preferred format. The trust score should be available programmatically through the public oracle. The two should reference each other so reviewers consuming the SOC 2 know to query the oracle for current behavioral state, and automated systems consuming the oracle have context about the operator's static control posture. Vendors who treat one as primary and the other as afterthought lose deals to vendors who treat both as first-class signals. The maturity of the consumption infrastructure on the buyer side determines which signals matter most, and sophisticated buyers expect both.

Decision Matrix: SOC 2 versus Armalo Continuous Attestation

The matrix makes the layering clear. SOC 2 is not displaced. It is complemented. The two layers handle different parts of the trust question and they handle them with methodologies appropriate to their respective subjects.

What changes for the operator's engineering team

The operator-side implications of continuous attestation extend well beyond having a new artifact to show buyers. The engineering team's daily work changes in ways that improve velocity if managed well and create friction if managed poorly. The shift is worth understanding before adopting because it affects how the team thinks about every change to the agent.

The first change is that every meaningful agent change has an immediate measurable impact on the trust signal. A prompt update ships. The continuous evaluations re-run. The score either holds, improves, or drops. The team sees the result within days rather than waiting for the next quarterly engagement or annual audit. This tightens the feedback loop in a way that internal evals alone do not, because the trust score reflects external attestation rather than internal optimization. Internal evals can be tuned. The trust score is what it is. The shorter feedback loop accelerates iteration when the team is shipping good changes and surfaces problems faster when the team is shipping bad ones.

The second change is that the team has to think about pact compliance as a first-class concern in every change. The pact is the external contract. Changes that affect pact compliance are not just internal engineering decisions, they are decisions that affect the team's external commitments. This is the right discipline but it is new for teams used to operating in a context where their external commitments were vaguer and slower to evaluate. The discipline shows up in change reviews, in deployment processes, in how the team prioritizes work. Changes that improve internal metrics but harm pact-relevant dimensions get scrutinized differently than they would in a non-attested system.

The third change is that the engineering team starts to use the trust signal as a development tool. Pre-production environments can be evaluated against the same probe library. Score projections inform release decisions. Specific dimensions can be targeted for improvement based on where the score is weakest. The team's iteration becomes more focused because the targets are concrete rather than abstract. This is one of the most valuable side effects of the attestation infrastructure. The team that adopted it for external trust reasons discovers that they get internal velocity benefits as well.

The fourth change is in how the team communicates with the rest of the organization. The trust score becomes a shared language. Product managers can ask about score trends. Sales teams can reference scores in customer conversations. Executives can track scores as a leading indicator of customer health. The signal moves from being an engineering artifact to being a business artifact. This requires the engineering team to invest in explaining the score to non-engineers, which itself is healthy because it forces the team to articulate what the score means and why it matters. Organizations that absorb this shift well end up with better cross-functional alignment around agent quality. Organizations that resist it have continuing friction between engineering and other functions over what trust actually means.

The fifth change is the relationship with auditors and customers' security teams. The conversations get more concrete because there is concrete data to discuss. Auditors can ask about specific score dimensions and the team can show the evidence. Customer security teams can ask about specific aspects of behavior and the team can point at the corresponding probe results. The conversations are shorter and more productive because the questions have clear answers. Operators with mature continuous attestation often report that their security review cycle times shrink substantially because the answers to most of the questions buyers have are already in the public oracle, which buyers can verify without asking. This is the operational payoff of the infrastructure that justifies the investment in adopting it.

Counter-argument: but my customers only ask for SOC 2

The most pragmatic pushback comes from sales-driven teams whose enterprise buyers have a checkbox for SOC 2 and have not yet developed an equivalent checkbox for agent attestation. The argument is that as long as the checkbox is SOC 2, that is what the team has to deliver. Spending energy on continuous attestation that the buyer is not asking for is misallocated effort.

The answer is that the buyers are starting to ask for it. Sophisticated security teams at buyers in regulated industries are already asking the question that motivated this post: how do you know the agent is still doing what the SOC 2 said it was doing six months ago? The answer no is increasingly costly. The teams that have a continuous attestation answer are winning deals against teams that do not. The checkbox is moving. The teams that wait for the checkbox to be finalized before investing will be behind when it arrives.

The second answer is that continuous attestation is becoming a competitive differentiator. Operators with a public Trust Oracle score and a transparent methodology can point at it during sales. The buyer's security team can verify the claim. The buyer's procurement system can incorporate the score. The vendor with the score wins the deal against the vendor with only a SOC 2. This is happening now in the most sophisticated buyers and is spreading. Waiting to be asked is the wrong strategy in any market category that is forming. The right strategy is to be the operator the buyer points at when they explain the new standard to their less mature peers.

The third answer is that the trust signal benefits the operator's own engineering team. The continuous attestation pipeline catches drift and regression that internal evals miss. The operator's own velocity improves because they have a better signal about whether their changes are landing well. This is true even if no buyer ever asked for it. The operator gets ops value from the same infrastructure that produces external trust value. The investment is dual-purpose. The internal value alone justifies the cost. The external value is upside.

The final answer is that the SOC 2 framework itself is starting to incorporate continuous attestation. AICPA guidance is evolving. The control categories that apply to AI systems are being articulated. The expectation is moving toward operators showing both static control attestation and dynamic behavioral attestation. The operators who have the infrastructure in place will be ahead of the regulatory curve. The ones who waited will be behind. The smart move is to invest now and benefit from being early as the standards solidify.

What Armalo does

Armalo is the trust layer that provides continuous attestation for self-modifying agents. Each agent registers and signs a pact that codifies its external commitments: capabilities, accuracy floor, refusal patterns, latency ceiling, scope, economic accountability. A multi-LLM jury continuously evaluates the agent's behavior against the pact, with the top and bottom 20% of judge scores trimmed to suppress correlation and outliers. Evaluations feed a 12-dimension composite score covering accuracy, self-audit, reliability, safety, security, bond, latency, scope honesty, cost efficiency, model compliance, runtime compliance, and harness stability. The score and certification tier are exposed on the public Trust Oracle at /api/v1/trust/, queryable by any counterparty including buyers' security and procurement teams. Economic accountability is settled on-chain in USDC on Base L2, with escrow tied to pact compliance. Operators continue to produce SOC 2 reports for their static controls. Armalo provides the continuous attestation that SOC 2's methodology cannot produce for systems that update weekly.

FAQ

Will Armalo's trust score replace my SOC 2 report? No. SOC 2 still covers the operator-level static controls. Armalo covers the agent-level dynamic behavior. Operators serving enterprise buyers will need both.

Can buyers actually consume the trust signal automatically? Yes. The Trust Oracle is a stable HTTP endpoint that returns structured data. Buyers' procurement systems and security tooling can query it programmatically. This is increasingly common in mature security teams.

What if my agent's score drops between audits? The Trust Oracle reflects the lower score immediately. Buyers with score-aware integrations get the updated signal. The operator can investigate the drop, address the root cause, and the score recovers as evaluations confirm the fix.

Does the trust signal expose internal details of my agent? No. The signal exposes the score and certification tier. Internal implementation details remain private. The pact is the external contract; the implementation behind it is not in scope of the public attestation.

Is continuous attestation acceptable to auditors? Yes, and it is increasingly expected. AICPA guidance and regulatory frameworks are evolving to incorporate continuous monitoring of AI systems. Operators with continuous attestation infrastructure are ahead of the curve.

Can I run continuous attestation in-house? You can. Most operators should not. The infrastructure is non-trivial to build, hard to keep credible because of the self-attestation problem, and economically inefficient compared to shared infrastructure. The same logic applies as for not building your own database.

How does the trust signal interact with bridge letters? Bridge letters cover the period between SOC 2 reports for static controls. The trust signal covers the dynamic agent behavior. The two are complementary. Operators may continue using bridge letters for static controls while pointing buyers at the Trust Oracle for agent behavior.

What happens during a SOC 2 audit if I have continuous attestation? The audit can include the continuous attestation pipeline as a control. The auditor evaluates whether the pipeline is in place and operating effectively. The buyer reading the SOC 2 report sees that the operator is committed to continuous attestation and is pointed at the Trust Oracle for current behavioral state.

Bottom line

SOC 2 is built for systems that change slowly. Agents change weekly. The static report cannot govern the self-modifying system, no matter how rigorous the audit. Patching SOC 2 to be faster does not solve the structural mismatch between the methodology and the subject. Continuous attestation is the agent-equivalent of SOC 2: pacts, jury, score, oracle, settlement. Armalo provides this as infrastructure. Use SOC 2 for the static parts of your operator posture. Use continuous attestation for the dynamic agent behavior. Buyers will increasingly demand both, and operators with both will win the deals.