{
  "schemaVersion": "1.0",
  "title": "AIP security policy",
  "description": "If you believe you found a vulnerability in AIP, email with the subject prefix [SECURITY]. Do not open a public issue or publish credentials, customer data, exploit payloads, or affected deployment identifiers before remediation has been co",
  "canonical": "https://getaip.org/docs/project/security",
  "route": "/docs/project/security",
  "source": "SECURITY.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Project and Releases",
  "documentType": "Project policy",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/project/security.md",
    "txt": "/docs/download/project/security.txt",
    "json": "/docs/download/project/security.json",
    "pdf": "/docs/download/project/security.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: AIP security policy\ndescription: Report a vulnerability privately and understand how the AIP project coordinates remediation\nkind: policy\naudience: security-reviewer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# AIP security policy\n\nIf you believe you found a vulnerability in AIP, email <hi@getaip.org> with\nthe subject prefix `[SECURITY]`. Do not open a public issue or publish\ncredentials, customer data, exploit payloads, or affected deployment\nidentifiers before remediation has been coordinated.\n\nSend the smallest safe report that lets the maintainers understand the issue.\nYou do not need a complete exploit or severity score before reporting a\ncredible concern.\n\n## What to report here\n\nUse this process for a suspected security weakness in AIP-owned material,\nincluding:\n\n- native protocol validation, signatures, identity, authorization, replay,\n  approval, or audit behavior;\n- runtime, storage, transport, MCP, A2A, or webhook implementations;\n- connector SDK, connector fleet, admission, registry, host, or control-plane\n  behavior;\n- one of the six maintained product connectors or its standalone host;\n- generated AIP schemas, release automation, published images, attestations,\n  or source-boundary inventories;\n- documentation or examples when following them could expose secrets, weaken a\n  security boundary, or misrepresent a required control.\n\nReport uncertainty. If it is unclear whether a defect belongs to AIP, an\nupstream product, or a dependency, send the relevant boundary information and\nlet the maintainers route it.\n\n## What belongs elsewhere\n\nUse the owning project's security process for a defect that exists only in an\nupstream product or third-party dependency. Also report it to AIP when the AIP\nintegration exposes the defect in a new way, bypasses an expected control, or\nships an affected artifact.\n\nUse these routes for other concerns:\n\n- report harassment, retaliation, or other community behavior through the\n  private process in the [code of conduct](CODE_OF_CONDUCT.md);\n- propose an ordinary code or documentation correction through the\n  [contribution workflow](CONTRIBUTING.md);\n- use the deployment owner's incident process for an outage, abuse event, or\n  compromised account that does not demonstrate an AIP vulnerability.\n\nThe AIP project is not an emergency service. If people are in immediate danger,\ncontact the appropriate local emergency service or platform safety channel.\n\n## Version and asset scope\n\nThe selected source proves the following version facts:\n\n| Target | Evidence at the reviewed revision | Reporting guidance |\n|---|---|---|\n| AIP `v1.0.0` | One source tag exists | Report suspected vulnerabilities |\n| Reviewed mainline source | Workspace version remains `1.0.0` after the tag | Report issues against the exact commit |\n| Earlier versions, forks, and modified images | No support or backport schedule is published in the selected source | Include the exact identity; response may require reproduction on an AIP-owned target |\n\nThis table records source evidence, not a promise to backport every fix. The\nproject has not published a fixed end-of-life schedule, patch cadence, or\nsupported-version matrix beyond the version information above.\n\nA protocol version alone does not make a deployment secure. Identity-provider\nconfiguration, credentials, storage, network policy, connectors, upstream\nservices, and exact image digests remain deployment-owned boundaries.\n\n## Contain immediate exposure first\n\nIf a credential, signing key, token, database URL, customer payload, or other\nsecret is exposed, begin the authorized deployment's containment procedure\nbefore expanding the investigation:\n\n1. stop the unsafe operation when doing so will not increase harm;\n2. revoke or rotate the exposed credential through its owning system;\n3. restrict access to affected logs, artifacts, and accounts;\n4. preserve the minimum records needed to understand the event;\n5. report the suspected AIP weakness and state which containment steps occurred.\n\nDo not send a live secret in the report. Redact it while preserving its type,\nlocation, scope, and relevant prefix or hash. If ordinary email is unsuitable\nfor the remaining evidence, send a minimal initial report and request a safer\ntransfer method. The project does not publish a PGP key in the selected source.\n\nFor active exploitation, use the deployment owner's incident-response process\nin parallel. A vulnerability report does not replace containment, customer\ncommunication, legal review, or regulatory obligations owned by the affected\noperator.\n\n## What to include\n\nInclude what is known and safe to share:\n\n- the affected AIP crate, binary, transport, profile, connector, image, schema,\n  or documentation path;\n- the exact source commit, release tag, image digest, package version, and\n  deployment topology when available;\n- prerequisites, configuration, trust boundary, and attacker position;\n- minimal reproduction steps and a redacted request, payload, trace, or log;\n- observed behavior and the behavior you expected;\n- likely impact on confidentiality, integrity, availability, authorization,\n  tenant isolation, audit evidence, or supply-chain integrity;\n- whether credentials, customer data, model output, or external provider state\n  may be affected;\n- whether exploitation is active or public and which mitigations are already\n  known;\n- a safe contact method and whether you want public credit.\n\nDo not collect unrelated customer records, broaden access, establish\npersistence, or prove impact by changing external state. A narrowly scoped\nreport is preferable to a more damaging demonstration.\n\n## How the project handles a report\n\nThe maintainers use the following process:\n\n1. A maintainer acknowledges the report when practical and establishes the\n   next communication step. No fixed response-time SLA is published.\n2. Access is limited to people needed to assess the issue. Anyone with a\n   material conflict should recuse from the decision.\n3. The report is checked against an AIP-owned revision or artifact in an\n   isolated, non-customer environment when possible.\n4. The reviewer identifies affected components, versions, trust boundaries,\n   deployment assumptions, and credible impact.\n5. Immediate mitigations are separated from the durable correction. Operators\n   may need a configuration restriction before a fixed artifact exists.\n6. A correction is reviewed with the relevant negative tests, schemas,\n   conformance behavior, documentation, and release evidence.\n7. Affected operators or upstream owners are coordinated when their action is\n   required for safe remediation.\n8. The project determines whether to publish an advisory, release note,\n   mitigation notice, corrected artifact, or a combination of them.\n\nThe exact order may change to contain active harm. Receipt of a report does not\nconfirm a vulnerability, severity, affected version, or remediation outcome.\n\n## Confidentiality and coordinated disclosure\n\nThe project limits report details to a need-to-know basis, but cannot promise\nanonymity or absolute confidentiality. Disclosure may be required for safe\nremediation, affected-operator coordination, upstream reporting, repository\nhost action, or legal obligations.\n\nThe project has not published a fixed embargo period. Reporter and maintainers\nshould coordinate a disclosure date based on exploitability, active abuse,\navailability of mitigations, affected operators, upstream dependencies, and\nthe time needed to distribute a verified correction.\n\nA public advisory may describe:\n\n- affected and unaffected versions or artifact digests;\n- security impact and required attacker conditions;\n- mitigations, fixed versions, and verification steps;\n- relevant deployment assumptions and remaining limitations;\n- reporter credit when the reporter requests it and disclosure is safe.\n\nDo not treat silence or a delayed response as permission to publish secrets,\ncustomer data, or another party's protected information. A reporter may ask for\na status update or propose a disclosure date through the original thread.\n\n## Responsible research expectations\n\nWhen evaluating AIP security:\n\n- use systems and accounts you own or are explicitly authorized to test;\n- minimize access, requests, data retention, and provider-side effects;\n- stop when testing reaches customer data, another tenant, a live credential,\n  or a risk of material service disruption;\n- do not use social engineering, physical intrusion, denial of service,\n  destructive actions, persistence, or data exfiltration;\n- keep exploit material private while remediation is being coordinated;\n- follow applicable law and the terms governing the tested environment.\n\nThe selected source does not define a bug bounty, monetary reward, contractual\nsafe harbor, CVE-assignment authority, or immunity from third-party terms. This\npolicy does not create those promises.\n\nGood-faith reporting is welcome even when the issue is incomplete, cannot be\nreproduced, or is ultimately classified as a non-security defect. Deliberately\nfalse, coercive, or retaliatory reporting remains subject to the code of\nconduct.\n\n## Maintainer responsibilities\n\nMaintainers handling a report are responsible for:\n\n- protecting report data and avoiding unnecessary reproduction on live data;\n- distinguishing protocol, implementation, connector, upstream, artifact, and\n  deployment ownership;\n- documenting the affected identity and evidence behind a security claim;\n- ensuring that a mitigation does not silently weaken another trust boundary;\n- updating tests, schemas, documentation, release notes, and artifacts that\n  would otherwise preserve the defect or an unsafe instruction;\n- avoiding production-ready or fully secure claims that the evidence does not\n  establish;\n- crediting a reporter only with their consent.\n\nA passing source gate, vulnerability scan, signature, or conformance suite is\none evidence layer. It does not prove that an arbitrary deployment, upstream\nservice, identity system, or future configuration is secure.\n\n## Verify a remediated release\n\nWhen a fix is published, identify and verify the exact corrected artifact. Do\nnot rely only on a mutable image tag, local build ID, or version string.\n\nThe reviewed release workflow is designed to publish immutable multi-platform\nimage digests with SBOMs, provenance, keyless Cosign signatures, and build\nattestations. The presence and verification of those artifacts must still be\nconfirmed for the release that claims the correction.\n\nUse the release note to identify the change, the artifact reference to verify\nwhat was published, and the security architecture to reassess the affected\nboundary.\n\n## Related documentation\n\n- [Security model](docs/architecture/security-model.md)\n- [Implementation status](docs/reference/implementation-status.md)\n- [Release artifacts](docs/reference/release-artifacts.md)\n- [Contributing to AIP](CONTRIBUTING.md)\n- [AIP code of conduct](CODE_OF_CONDUCT.md)\n",
    "text": "AIP security policy\n\nIf you believe you found a vulnerability in AIP, email  with\nthe subject prefix [SECURITY]. Do not open a public issue or publish\ncredentials, customer data, exploit payloads, or affected deployment\nidentifiers before remediation has been coordinated.\n\nSend the smallest safe report that lets the maintainers understand the issue.\nYou do not need a complete exploit or severity score before reporting a\ncredible concern.\n\nWhat to report here\n\nUse this process for a suspected security weakness in AIP-owned material,\nincluding:\n• native protocol validation, signatures, identity, authorization, replay,\n  approval, or audit behavior;\n• runtime, storage, transport, MCP, A2A, or webhook implementations;\n• connector SDK, connector fleet, admission, registry, host, or control-plane\n  behavior;\n• one of the six maintained product connectors or its standalone host;\n• generated AIP schemas, release automation, published images, attestations,\n  or source-boundary inventories;\n• documentation or examples when following them could expose secrets, weaken a\n  security boundary, or misrepresent a required control.\n\nReport uncertainty. If it is unclear whether a defect belongs to AIP, an\nupstream product, or a dependency, send the relevant boundary information and\nlet the maintainers route it.\n\nWhat belongs elsewhere\n\nUse the owning project's security process for a defect that exists only in an\nupstream product or third-party dependency. Also report it to AIP when the AIP\nintegration exposes the defect in a new way, bypasses an expected control, or\nships an affected artifact.\n\nUse these routes for other concerns:\n• report harassment, retaliation, or other community behavior through the\n  private process in the code of conduct (CODEOFCONDUCT.md);\n• propose an ordinary code or documentation correction through the\n  contribution workflow (CONTRIBUTING.md);\n• use the deployment owner's incident process for an outage, abuse event, or\n  compromised account that does not demonstrate an AIP vulnerability.\n\nThe AIP project is not an emergency service. If people are in immediate danger,\ncontact the appropriate local emergency service or platform safety channel.\n\nVersion and asset scope\n\nThe selected source proves the following version facts:\n\n| Target | Evidence at the reviewed revision | Reporting guidance |\n\n| AIP v1.0.0 | One source tag exists | Report suspected vulnerabilities |\n| Reviewed mainline source | Workspace version remains 1.0.0 after the tag | Report issues against the exact commit |\n| Earlier versions, forks, and modified images | No support or backport schedule is published in the selected source | Include the exact identity; response may require reproduction on an AIP-owned target |\n\nThis table records source evidence, not a promise to backport every fix. The\nproject has not published a fixed end-of-life schedule, patch cadence, or\nsupported-version matrix beyond the version information above.\n\nA protocol version alone does not make a deployment secure. Identity-provider\nconfiguration, credentials, storage, network policy, connectors, upstream\nservices, and exact image digests remain deployment-owned boundaries.\n\nContain immediate exposure first\n\nIf a credential, signing key, token, database URL, customer payload, or other\nsecret is exposed, begin the authorized deployment's containment procedure\nbefore expanding the investigation:\n1. stop the unsafe operation when doing so will not increase harm;\n2. revoke or rotate the exposed credential through its owning system;\n3. restrict access to affected logs, artifacts, and accounts;\n4. preserve the minimum records needed to understand the event;\n5. report the suspected AIP weakness and state which containment steps occurred.\n\nDo not send a live secret in the report. Redact it while preserving its type,\nlocation, scope, and relevant prefix or hash. If ordinary email is unsuitable\nfor the remaining evidence, send a minimal initial report and request a safer\ntransfer method. The project does not publish a PGP key in the selected source.\n\nFor active exploitation, use the deployment owner's incident-response process\nin parallel. A vulnerability report does not replace containment, customer\ncommunication, legal review, or regulatory obligations owned by the affected\noperator.\n\nWhat to include\n\nInclude what is known and safe to share:\n• the affected AIP crate, binary, transport, profile, connector, image, schema,\n  or documentation path;\n• the exact source commit, release tag, image digest, package version, and\n  deployment topology when available;\n• prerequisites, configuration, trust boundary, and attacker position;\n• minimal reproduction steps and a redacted request, payload, trace, or log;\n• observed behavior and the behavior you expected;\n• likely impact on confidentiality, integrity, availability, authorization,\n  tenant isolation, audit evidence, or supply-chain integrity;\n• whether credentials, customer data, model output, or external provider state\n  may be affected;\n• whether exploitation is active or public and which mitigations are already\n  known;\n• a safe contact method and whether you want public credit.\n\nDo not collect unrelated customer records, broaden access, establish\npersistence, or prove impact by changing external state. A narrowly scoped\nreport is preferable to a more damaging demonstration.\n\nHow the project handles a report\n\nThe maintainers use the following process:\n1. A maintainer acknowledges the report when practical and establishes the\n   next communication step. No fixed response-time SLA is published.\n2. Access is limited to people needed to assess the issue. Anyone with a\n   material conflict should recuse from the decision.\n3. The report is checked against an AIP-owned revision or artifact in an\n   isolated, non-customer environment when possible.\n4. The reviewer identifies affected components, versions, trust boundaries,\n   deployment assumptions, and credible impact.\n5. Immediate mitigations are separated from the durable correction. Operators\n   may need a configuration restriction before a fixed artifact exists.\n6. A correction is reviewed with the relevant negative tests, schemas,\n   conformance behavior, documentation, and release evidence.\n7. Affected operators or upstream owners are coordinated when their action is\n   required for safe remediation.\n8. The project determines whether to publish an advisory, release note,\n   mitigation notice, corrected artifact, or a combination of them.\n\nThe exact order may change to contain active harm. Receipt of a report does not\nconfirm a vulnerability, severity, affected version, or remediation outcome.\n\nConfidentiality and coordinated disclosure\n\nThe project limits report details to a need-to-know basis, but cannot promise\nanonymity or absolute confidentiality. Disclosure may be required for safe\nremediation, affected-operator coordination, upstream reporting, repository\nhost action, or legal obligations.\n\nThe project has not published a fixed embargo period. Reporter and maintainers\nshould coordinate a disclosure date based on exploitability, active abuse,\navailability of mitigations, affected operators, upstream dependencies, and\nthe time needed to distribute a verified correction.\n\nA public advisory may describe:\n• affected and unaffected versions or artifact digests;\n• security impact and required attacker conditions;\n• mitigations, fixed versions, and verification steps;\n• relevant deployment assumptions and remaining limitations;\n• reporter credit when the reporter requests it and disclosure is safe.\n\nDo not treat silence or a delayed response as permission to publish secrets,\ncustomer data, or another party's protected information. A reporter may ask for\na status update or propose a disclosure date through the original thread.\n\nResponsible research expectations\n\nWhen evaluating AIP security:\n• use systems and accounts you own or are explicitly authorized to test;\n• minimize access, requests, data retention, and provider-side effects;\n• stop when testing reaches customer data, another tenant, a live credential,\n  or a risk of material service disruption;\n• do not use social engineering, physical intrusion, denial of service,\n  destructive actions, persistence, or data exfiltration;\n• keep exploit material private while remediation is being coordinated;\n• follow applicable law and the terms governing the tested environment.\n\nThe selected source does not define a bug bounty, monetary reward, contractual\nsafe harbor, CVE-assignment authority, or immunity from third-party terms. This\npolicy does not create those promises.\n\nGood-faith reporting is welcome even when the issue is incomplete, cannot be\nreproduced, or is ultimately classified as a non-security defect. Deliberately\nfalse, coercive, or retaliatory reporting remains subject to the code of\nconduct.\n\nMaintainer responsibilities\n\nMaintainers handling a report are responsible for:\n• protecting report data and avoiding unnecessary reproduction on live data;\n• distinguishing protocol, implementation, connector, upstream, artifact, and\n  deployment ownership;\n• documenting the affected identity and evidence behind a security claim;\n• ensuring that a mitigation does not silently weaken another trust boundary;\n• updating tests, schemas, documentation, release notes, and artifacts that\n  would otherwise preserve the defect or an unsafe instruction;\n• avoiding production-ready or fully secure claims that the evidence does not\n  establish;\n• crediting a reporter only with their consent.\n\nA passing source gate, vulnerability scan, signature, or conformance suite is\none evidence layer. It does not prove that an arbitrary deployment, upstream\nservice, identity system, or future configuration is secure.\n\nVerify a remediated release\n\nWhen a fix is published, identify and verify the exact corrected artifact. Do\nnot rely only on a mutable image tag, local build ID, or version string.\n\nThe reviewed release workflow is designed to publish immutable multi-platform\nimage digests with SBOMs, provenance, keyless Cosign signatures, and build\nattestations. The presence and verification of those artifacts must still be\nconfirmed for the release that claims the correction.\n\nUse the release note to identify the change, the artifact reference to verify\nwhat was published, and the security architecture to reassess the affected\nboundary.\n\nRelated documentation\n• Security model (docs/architecture/security-model.md)\n• Implementation status (docs/reference/implementation-status.md)\n• Release artifacts (docs/reference/release-artifacts.md)\n• Contributing to AIP (CONTRIBUTING.md)\n• AIP code of conduct (CODEOFCONDUCT.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "6659d3f714724b9285921489df9c6cb4af836891c3323b23b2f09ad3c1eaab56"
  }
}